نحوه Dialplan نویسی در گیت وی های سنگوما (Sangoma SS7 Voip Gateway)

[Habili]

زمانیکه یک تماس در گیت وی Sangoma SS7 از بستر پروتکل های SIP, H323 یا SS7 دریافت میشود، از دایال پلن برای مشخص کردن rout ی که data باید برای پیدا کردن مسیر تماس خروجی از آن استفاده کند، استفاده میشود. :)

نکته : Dialplan در مد MG/Megaco/H.248 استفاده نمیشود. MGCP خودش routing را انجام میدهد.

تنظیمات دایال پلن PSTN به SIP در گیت وی های سنگوما (به زودی)
تنظیمات دایال پلن SIP به PSTN در گیت وی های سنگوما (به زودی)


همچنین توصیه میشود مقالات زیر را هم مطالعه فرمایید.

تاپیک جامع آموزش دیال پلن (Dialplan) نویسی در استریسک

نحوه ترانک گیت وی های سنگوما و الستیکس

امنیت در سیستم های تلفنی ویپ (استریسک، الستیکس و ...)

معرفی کدک های SIP/IAX/H323/MGCP/ در استریسک



نحوه دسترسی به بخش تنظیمات Dialplan :

از منوی Configuration زیر منوی DialPlan را انتخاب کنید.
یک متغییر را تغییر دهید و روی Save (آیکون Disk) کلیک کنید.
به کنترل پنل برگردید و Voip Gateway را Restart کنید.




Dialplan برای موارد زیر از پیش کانفیگ شده است.

• تماس های از سمت SIP به TDM و TDM به سمت SIP

قسمت from-sip تماس ها را از SIP به PSTN/SS7 روت میکند.
بخش from-pstn تماس ها را از PSTN/SS7 به SIP روت میکند.

• تماس های از سمت H323 به TDM و از TDM به H323

بخش from-h323 تماس ها را از H323 به PSTN روت میکند.



Reload/Apply کردن Dialplan

توجه کنید که دایال پلن میتواند به صورت realtime و بدون نیاز به restart کردن گیت وی تغییر داده شود. به محض اینکه Dialplan را Save کنید از شما درخواست میشود گیت وی را reload کنید که تغییرات را بدون هیچ وقفه ای در سرویس، اعمال خواهد کرد. تمام تماس هایی که در آن لحظه برقرار شده اند هیچ گونه وقفه ای در آنها ایجاد نخواهد شد. تنها تماس هایی که جدید ایجاد شوند از قوانین دیال پلن جدید استفاده خواهند کرد.



Dialplan از PSTN به SIP

به صورت پیش فرض NSG (مخفف Netboarder SS7 Gateway) به نحوی تنظیم شده است که یک تماس را به یک IP آدرس SIP ارسال کند. آدرس سرور ریموت SIP باید در قسمت Configuration -> Global تعریف شده باشد.

<context name="[B]from-pstn-to-sip[/B]">
<extension name="to-sip">
<!-- handle the case where there might not be destination number at all -->
<condition field="destination_number" expression="^(.{1,})$" break="never">
<action application="set" data="destnumber=$1"/>
<anti-action application="set" data="destnumber=unknown"/>
</condition>
<!-- Dial to the gateway user (it may ring multiple registrations, first answer wins) -->
<condition field="destination_number" expression="^(.*)$">
<action application="set" data="hangup_after_bridge=yes" />
<action application="set" data="tone_detect_hits=1" />
<action application="export" data="fax_enable_t38_request=true" />
<action application="export" data="fax_enable_t38=true" />
<action application="tone_detect" data="faxdisable 1100 r +5000 disable_ec 1"/>
<action application="export" data="execute_on_answer=tone_detect fax_disable_ec 2100 r +5000
t38_gateway 'self nocng'" />
<action application="set" data="sip_contact_user_replacement=${destnumber}"/>
<action application="set" data="hangup_after_bridge=yes"/>
[B][COLOR=#000080]<action application="bridge" data="sofia/internal/${destnumber}@${sip_dest_ip}:${sip_dest_port}"/>[/COLOR][/B]
<action application="hangup" data="${originate_disposition}"/>
</condition>
</extension>
</context>

Dialplan برای PSTN به H323

به صورت پیش فرض NSG به نحوی تنظیم شده است که یک تماس را به یک IP آدرس H323 ارسال کند. آدرس سرور ریموت H323 باید در قسمت Configuration -> Global تعریف شده باشد.

<context name="[B]from-pstn-to-h323[/B]">
<extension name="to-h323">
<!-- handle the case where there might not be destination number at all -->
<condition field="destination_number" expression="^(.{1,})$" break="never">
<action application="set" data="destnumber=$1"/>
<anti-action application="set" data="destnumber=unknown"/>
</condition>
<!-- Dial to the gateway user (it may ring multiple registrations, first answer wins) -->
<condition field="destination_number" expression="^(.*)$">
<action application="set" data="hangup_after_bridge=yes" />
<action application="set" data="tone_detect_hits=1" />
<action application="export" data="fax_enable_t38_request=true" />
<action application="export" data="fax_enable_t38=true" />
<action application="tone_detect" data="faxdisable 1100 r +5000 disable_ec 1"/>
<action application="export" data="execute_on_answer=tone_detect fax_disable_ec 2100 r +5000
t38_gateway 'self nocng'" />
<action application="set" data="sip_contact_user_replacement=${destnumber}"/>
<action application="set" data="hangup_after_bridge=yes"/>
[B][COLOR=#000080]<action application="bridge" data="opal/h323:${destination_number}@${h323_remote_ip}"/>[/COLOR][/B]
<action application="hangup" data="${originate_disposition}"/>
</condition>
</extension>
</context>
</include>

Dialplan برای SIP/H323 به PSTN

توجه کنید که هر دو پروفایل SIP و H323 کانتکست یکسانی با نام from-sip را share میکنند. کانتکست from-sip تمامی تماس ها را به اینترفیس TDM پاس خواهد داد.

<?xml version="1.0" encoding="utf-8"?>
<include>
<context name="from-sip">
<extension name="to-pstn">
<!-- retrieve group and hunting parameters if present -->
<condition field="destination_number" expression="([0-9a-zA-Z]+)(-g=[a-zA-Z0-9]+)?(-h=[a|A])?(-fax)?"
break="never">
<action inline="true" application="set" data="group=$2"/>
<action inline="true" application="set" data="hunting=$3"/>
<action inline="true" application="set" data="faxcall=$4"/>
</condition>
<!-- check if there is a group and set a default if not present -->
<condition field="${group}" expression="^-g=([a-zA-Z0-9]+)$" break="never">
<action application="set" data="group=$1"/>
<anti-action application="set" data="group=$${pstn_default_group}"/>
</condition>
<!-- check if there is a hunting policy and set a default if not present -->
<condition field="${hunting}" expression="^-h=([a|A])$" break="never">
<action application="set" data="hunting=$1"/>
<anti-action application="set" data="hunting=${pstn_default_hunting}"/>
</condition>
<!-- Do the actual pstn dialing -->
<condition field="destination_number" expression="^([0-9a-zA-Z]+)">
<action application="set" data="hangup_after_bridge=yes" />
<action application="answer" />
<action application="export" data="nolocal:tone_detect_hits=1" />
<action application="set" data="fax_enable_t38_request=true" />
<action application="set" data="fax_enable_t38=true" />
<action application="export" data="nolocal:execute_on_answer_1=tone_detect fax_disable_ec
2100 r +5000 disable_ec 1" />
<action application="export" data="nolocal:execute_on_answer_2=t38_gateway peer
ced_preamble" />
<action application="set" data="hangup_after_bridge=yes"/>
[B][COLOR=#000080]<action application="bridge" data="freetdm/${group}/${hunting}/$1"/>[/COLOR][/B]
<action application="hangup" data="${originate_disposition}"/>
</condition>
</extension>
</context>

ساختار Dialplan

برای ایجاد یک دایال پلن XML از چندین element استفاده میشود. به صورت کلی دیال پلن function های مشابه و فعالیت های مربوط به تماس را به طور منطقی در یک context گروه بندی میکند. درون یک کانتکست extension هایی هستند که هر کدام rule های شرطی مربوط به خود را دارند و همچنین action های مربوطه که به هنگام match شدن شرط ها آن action ها اجرا میشوند.

نمونه زیر یک مثال از Dialplan برای نمایش مفاهیم بالا میباشد.

<context name="example">
<extension name="500">
<condition field="destination_number" expression="^500$">
<action application="bridge" data="user/500"/>
</condition>
</extension>
<extension name="501">
<condition field="destination_number" expression="^501$">
<action application="bridge" data="user/501"/>
<action application="answer"/>
<action application="sleep" data="1000"/>
<action application="bridge" data="loopback/app=voicemail:default ${domain_name} ${dialed_extension}"/>
</condition>
</extension>
</context> 

هر بخش به ترتیب پردازش میشود تا زمانیکه شما به تگ action برسید که به NSG میگوید که چه اکشنی را باید اجرا کند. شما محدود به استفاده کردن تنها از یک شرط یا تگ action برای یک extension نیستید.

در مثال بالا، تماس به داخلی 501 ابتدا باعث زنگ خوردن داخلی میشود اگر کاربر پاسخ ندهد action بعدی تماس را پاسخ میدهد سپس اکشن بعد تماس را به اندازه 1000 میلی ثانیه (1 ثانیه) منتظر نگه میدارد و تماس را به سیستم Voice Mail متصل میکند.



Context

کانتکست منطقا گروه بندی داخلی ها میباشند. شما ممکن است درون یک context چندین extension داشته باشید.

تگ context یک پارامتر اجباری تحت عنوان name دارد. که یک نام رزرو شده میباشد که با هر context ی match میشود. name توسط کنترل کننده تماس های ورودی برای انتخاب Dialplan ی که به هنگام نیاز برای route یک تماس اجرا میشود، استفاده می گردد. (مثل [Sofia] SIP driver). قالبا بیشتر از یک context در یک دیال پلن موجود است.

یک نمونه Dialplan با تنظیمات کامل در زیر نمایش داده شده است. عموما شما نیاز به همه بخش ها ندارید اما به اجمال در زیر نمایش داده شده اند.

<?xml version="1.0"?>
<document type="freeswitch/xml">
<section name="dialplan" description="Regex/XML Dialplan">
<!-- the default context is a safe start -->
<context name="default">
<!-- one or more extension tags -->
</context>
<!-- more optional contexts -->
</section>
</document>

Extensions

Extension ها در حقیقت مقصد های یک تماس هستند. در حقیقت extension خوراک شماره های گرفته شده و route داده شده در NSG هستند. به آنها یک نام و گروهی از شرط ها را میدهیم، که در صورتی که شرط ها برقرار شوند اکشن های مشخص اجرا خواهند شد.

پارامتر name ضروری میباشد که باید یک نام uniq اختصاص داده شده به یک extension باشد تا بتوان آن را شناسایی و بعدا از آن استفاده کرد.

برای مثال :

<extension name="Your extension name here">
<condition(s)...
<action(s) .../>
</condition>
</extension> 

نکته : عموما هنگامی که یک extension در Dialplan شما match میشود اکشن های مربوطه اجرا میشوند و پروسه Dialplan متوقف میشود. پارامتر اختیاری continue به دیال پلن شما امکان ادامه به اجرا شدن را خواهد داد.

<extension name="500" continue="true"> 

Conditions

شرط های Dialplan عموما برای match شدن یک شماره مقصد با یک extension استفاده میشود. به هر حال آنها بیشتر از آنچه که در سطح شان به نظر میرسد قدرت دارند. NSG شامل مجموعه متغییرهای داخلی میباشد که برای تست مورد استفاده قرار میگیرند. در این مثال متغییر built-in (درونی) destination_number با عبارت خاص (regular expression) زیر (^500$) مقایسه میشود. نتیجه این مقایسه در صورتی که متغییر destination_number برابر با 500 باشد، true است.

<extension name="500">
<condition field="destination_number" expression="^500$">
<action application="bridge" data="user/500"/>
</condition>
</extension> 

هر شرط با استفاده از کتابخانه Perl Compatible Regular Expression تجزیه و تحلیل میشود. (برای دریافت اطلاعات ساختاری PCRE به اینجا مراجعه کنید).

اگر یک عبارت خاص (regular expression) شامل هر عبارتی در پرانتز باشد و عبارت match شود سپس متغییرهای $1,$2..$N برای محتوای match شده در پرانتز تعریف خواهند شد و ممکن است در تگ های اکشن بعدی درون بلاک extension مورد استفاده قرار گیرند.

برای مثال، عبارت ساده زیر با شماره extension چهار رقمی match میشود و دو عدد آخر را درون متغییر $1 قرار میدهد. در حقیقت $1 برابر با بخشی از عبارت خاص میباشد که درون پرانتز "()" قرار گرفته است.

<condition field="destination_number" expression="^\d\d(\d\d)$">
<action application="bridge" data="sofia/internal/$1@example.com"/>
</condition> 

به طور مثال برای شماره مقصد 3425 متغییر $1 برابر با 25 تعریف میشود و در نهایت تماس را به سمت تلفن 25@example.com ارسال میکند.



Multiple Conditions (AND منطقی)

شما میتوانید از عملیات AND موجود در زبان برنامه نویسی بیشماری استفاده کنید و چندین شرط را داشته باشید. زمانیکه شما بیشتر از یک شرط را در یک extension قرار میدهید تمامی شرط ها باید قبل از اینکه action ها اجرا شوند، match شده باشند. برای مثال، کد زیر تنها زمانی action ها را اجرا خواهد کرد که destination number برابر با 500 باشد همچنین روز جاری یکشنبه باشد.

<condition field="destination_number" expression="^500$"/>
<condition wday="1">
action(s)...
</condition> 

به خاطر داشته باشید که شما باید syntax درست XML را به هنگام استفاده از این ساختار در نظر بگیرید. مطمئن شوید که تمامی شرط ها به غیر از شرط آخر را با /> ببندید. شرط آخر شامل اکشن های نهایی برای اجرا میباشند و در نتیجه در خط بعد از آخرین اکشن بسته میشوند.

به صورت پیش فرض اگر هر شرطی false باشد، NSG بدون اجرا کردن هیچ action ی یا هدایت به سمت extension دیگری به کار خود ادامه خواهد داد حتی شرط های دیگر را نیز مورد بررسی قرار نمیدهد.



Multiple Conditions (OR, XOR منطقی)

شما میتوانید از عملیات OR موجود در زبان برنامه نویسی بیشماری استفاده کنید و چندین شرط را داشته باشید. در این مورد اگر یکی از شرط ها match شوند سپس اکشن ها اجرا خواهند شد. برای مثال نمونه زیر در صورتی که distination number برابر با 501 یا 502 باید اکشن هایش را اجرا خواهد کرد.

<condition field="destination_number" expression="^501|502$">
action(s)...
</condition> 

این متد در صورتی به خوبی کار میکند که شرط OR شما برای فیلد یکسانی باشد. به هر حال اگر شما نیاز به استفاده از دو فیلد متفاوت و یا بیشتر باشیم باید از ساختار regex جدید استفاده کنیم.

<extension name="Regex OR example 1" continue="true">
<condition regex="any">
<!-- If either of these is true then the subsequent actions are added to execute list -->
<regex field="caller_id_name" expression="Some User"/>
<regex field="caller_id_number" expression="^1001$"/>
<action application="log" data="INFO At least one of the conditions matched!"/>
<!-- If *none* of the regexes is true then the anti-actions are added to the execute list -->
<anti-action application="log" data="WARNING None of the conditions matched!"/>
</condition>
</extension> 

استفاده از این روش باعث میشود که نام تماس گیرنده (Caller's Name) یا شماره تماس گیرنده (Caller ID Number) آسانتر match شود و در صورتی که شرط true بود اکشن ها اجرا شود. یک نمونه پیشرفته تر از استفاده این روش را میتوانید در زیر مشاهده کنید.

<extension name="Regex OR example 2" continue="true">
<condition regex="any" break="never">
<regex field="caller_id_name" expression="^Michael\s*S?\s*Collins"/>
<regex field="caller_id_number" expression="^1001|3757|2816$"/>
<action application="set" data="calling_user=mercutioviz" inline="true"/>
<anti-action application="set" data="calling_user=loser" inline="true"/>
</condition>
<condition>
<action application="answer"/>
<action application="sleep" data="500"/>
<action application="playback" data="ivr/ivr-welcome_to_freeswitch.wav"/>
<action application="sleep" data="500"/>
</condition>
<condition field="${calling_user}" expression="^loser$">
<action application="playback" data="ivr/ivr-dude_you_suck.wav"/>
<anti-action application="playback" data="ivr/ivr-dude_you_rock.wav"/>
</condition>
</extension>
<extension name="Regex XOR example 3" continue="true">
<condition regex="xor">
<!-- If only one of these is true then the subsequent actions are added to execute list -->
<regex field="caller_id_name" expression="Some User"/>
<regex field="caller_id_number" expression="^1001$"/>
<action application="log" data="INFO Only one of the conditions matched!"/>
<!-- If *none* of the regexes is true then the anti-actions are added to the execute list -->
<anti-action application="log" data="WARNING None of the conditions matched!"/>
</condition>
</extension> 

اساسا برای این چنین ساختار جدیدی شما میتوانید برای داشتن یک regex به جای field و expression و یا غیره یک شرط داشته باشید. هنگامی که یک regex موجود است این به این معنی است که شما قصد دارید، یک تگ (regex) یا بیشتر داشته باشید که شبیه به تگ condition باشد و دارای field و expression درون خودش باشد.

مقدار regex میتواند all یا any باشد و یا xor ی که مشخص کند آیا همه عبارات باید match شوند یا فقط هر عبارت یا تنها یکی از عبارات باید match شود (XOR). اگر این مقدار برابر با any تعریف شود تست کردن تگ های regex به محض اینکه یک match پیدا شود متوقف خواهد شد. و اگر بربر با all تعریف شده باشد به محض اینکه یک مورد نقض پیدا شود متوقف خواهد شد.

از اینجا مشخص است که این مورد شبیه به یک تگ شرط normal رفتار خواهد کرد، خواه با اجرای اکشن ها باشد یا بدون اجرای اکشن ها و همچنین ایجاد وقفه براساس قسمت breake

تفاوت اساسی در اینجا وجود regex است. تگ های regex برای مقادیر all یا any که در field یا condition مجزا قرار بگیرند تجزیه و تحلیل میشوند.

نکته : همچنین اگر هر گونه capture در قسمت expression از یک تگ regex انجام شود تنها data ی جدیدترین capture که با آن مواجه میشود را در متغییر $n یا FIELD_DATA بررسی خواهد کرد. علاوه بر این شما میتوانید DP_REGEX_MATCH_1 .. DP_REGEX_MATCH_N را به منظور نگه داشتن capture ها درون آرایه ها (arrays) تعریف کنید.

<extension name="Inbound_external">
<condition regex="any">
<regex field="${sip_from_host}" expression="domainA"/>
<regex field="${sip_from_uri}" expression="1234567890@domainB"/>
<regex field="${sip_from_uri}" expression="user@domainC"/>
<regex field="caller_id_name" expression="^(John Smith)$"/>
<regex field="caller_id_number" expression="^(55512341)|(55512342)|(55512343)$"/>
<action application="set" data="domain_name=domainZ"/>
<action application="transfer" data="${destination_number} XML domainZ"/>
</condition>
</extension> 

مثال بالا نمونه ی دیگریست که نشان میدهد همه شرط های regex باید true باشند، در این صورت است که اکشن ها متعاقبا اجرا میشوند. در غیر اینصورت هیچ اکشنی اجرا نمیشود، و در حقیقت با منطق زیر یکسان است.

IF (cond1 AND cond2 AND cond3) THEN
do actions
ELSE
do other actions
ENDIF 

اساسا، <condition regex="all"> به مفسر اعلام میکند که action ها را تنها در صورتی اجرا کند که همه (all) regex ها پاس شوند در غیر اینصورت هیچ اکشنی اجرا نشود.

<condition regex="all">
<regex field="${sip_gateway}" expression="^${default_provider}$"/>
<regex field="${emergency_call}" expression="^true$"/>
<regex field="${db(select/emergency/autoanswer)}" expression="^1$"/>
<!-- the following actions get executed if all regexes PASS -->
<action application="set" data="call_timeout=60"/>
<action application="set" data="effective_caller_id_name=${regex(${caller_id_name}|^Emerg(_.*)$|Auto%1)}"/>
<action application="set" data="autoanswered=true"/>
<action application="bridge" data="user/1000@${domain_name},sofia/gateway/1006_7217/${mobile_number}"/>
<!-- the following anti-actions are executed if any of the regexes FAIL -->
<anti-action application="set" data="effective_caller_id_name=${regex(${caller_id_name}|^Emerg(_.*)$|NotAuto%1)}"/>
<anti-action application="set" data="call_timeout=30"/>
<anti-action application="set" data="autoanswered=false"/>
<anti-action application="bridge" data="user/1000@${domain_name},sofia/gateway/1006_7217/${mobile_number}"/>
</condition> 

Condition / Action های پیچیده

در اینجا یک مثال پیچیده تر را مشاهده می کنیم که برای یک شرکت پشتیبانی، مسیر دهی تماس را براساس زمان پیاده سازی می کند. کاربر شماره 1100 را شماره گیری می کند. داخلی اصلی پشتیبانی در حقیقت 1105 می باشد و هر روز از ساعت 8 صبح تا 10 شب و جمعه ها از ساعت 8 صبح تا 1 ظهر در شرکت حضور دارد و در این ساعت ها تماس به این داخلی وصل میشود. در ساعت های دیگر تماسهای به شماره ی 1100 به ویس میل ارسال میشود.

<extension name="Time-of-day-tod">
<!--if this is false, FreeSWITCH skips to the next *extension*.-->
<condition field="destination_number" expression="^1100$" break="on-false"/>
<!--Don't bother evaluating the next condition set if this is true.-->
<condition wday="6" hour="8-12" break="on-true"> <!--Fri, 8am-12:59pm-->
<action application="transfer" data="1105 XML default"/>
</condition>
<condition wday="1-5" hour="8-21" break="on-true"> <!--Sunday-Thursday, 8am-9:59pm-->
<action application="transfer" data="1105 XML default"/>
</condition>
<condition> <!--this is a catch all, sending the call to voicemail at all other times. -->
<action application="voicemail" data="default ${domain} 1105"/>
</condition>
</extension> 

در این مثال ما از پارامتر break=never استفاده کردیم تا باعث شود اولین شرط لحاظ نشود و به شرط بعدی مراجعه شود مهم نیست شرط اول true و یا false باشد. این مورد برای تعریف آپشن های خاص بعنوان بخشی از مرحله پردازش extension مورداستفاده و مفید است.مثال زیر درصورتی که destination number با عدد 1 شروع شود، متغیر begins_with_one را تعریف میکند.

<extension name="break-demo">
<!-- because break=never is set, even when the destination does not begin
with 1, we skip the action and keep going -->
<condition field="destination_number" expression="^1(\d+)$" break="never">
<action application="set" data="begins_with_one=true"/>
</condition>
<condition field="destination_number" expression="^(\d+)$">
...other actions that may query begins_with_one...
</condition>
</extension> 

Variables

عبارات شرطی می توانند بر اساس متغیرهای چنل (channel variables) یا یک سری از متغیرهای درونی (built-in) مچ شوند.



Built-In Variables

متغیرهای زیر caller profile fields نامیده می شوند و از قسمت عبارات شرطی میتوان به آنها مستقیما دسترسی داشت:

context : گروه بندی داخلی ها
rdnis : همان Redirected Number, شماره مقصدی که یک تماس در آخرسر به آن ارسال شده است
destination_number : همان Called Number, شماره ای که یک تماس میخواهد به آن وصل شود
dialplan : نام ماژول دیال پلنی که استفاده میشود و این نام توسط هر ماژول دیال پلن فراهم میآید مانند: xml
caller_id_name : نام تماس گیرنده که توسط ایجنت مخاطب برای ما فراهم میآید
caller_id_number : شماره تلفن مخاطبی که تماس گرفته که می تواند hidden شود
ani : یا Automatic Number Identification, شماره ی تماس گیرنده که نمی تواند hidden شود
aniii : نوع دیوایسی که تماس ANI2 را هندل می کند
uuid : یونیک آی دی (Unique identifier) تماس جاری (مانند GUID )
source : نام ماژول فری سوییچ که تماس را دریافت می کند (e.g. PortAudio)
chan_name : نام چنل جاری (مثلا: PortAudio/1234).
network_addr : آدرس آی پی سورس سیگنالینگ یک تماس ویپ
year : بمعنی Calendar year سال , 0-9999
yday : بمعنی Day of year روز از سال , 1-366
mon : بمعنی Month ماه, 1-12 (Jan = 1, etc.)
mday : بمعنی Day of month روز از ماه, 1-31
week : بمعنی Week of year هفته از سال, 1-53
mweek : بمعنی Week of month هفته از ماه , 1-6
wday : بمعنی Day of week روز از هفته , 1-7 (Sun = 1, Mon = 2, etc.) or "sun", "mon", "tue", etc
hour : بمعنی Hour ساعت, 0-23
minute : بمعنی Minute (از ساعت) دقیقه, 0-59
minute-of-day : بمعنی Minute of the day دقیقه از روز, (1-1440) (midnight = 1, 1am = 60, noon = 720, etc.)
time-of-day : بمعنی Time range formatted فرمت رنج ساعت : hh:mm[:ss]-hh:mm[:ss] (seconds optional) Example: "08:00-17:00"
date-time : بمعنی Date/time range formatted فرمت رنج تاریخ/ساعت : YYYY-MM-DD hh:mm[:ss]~YYYY-MM-DD hh:mm[:ss] (seconds optional, note
tilde between dates) Example: 2010-10-01 00:00:01~2010-10-15 23:59:59


به طور مثال :

<condition field="network_addr" expression="^192\.168\.1\.1$"/> <!-- network address=192.168.1.1 >
<condition mon="2"> <!-- month=February --> 

فیلدهای Caller Profile در مقابل متغیرهای چنل (channel variable)

موردی که ممکن است گیج کننده باشد تشخیص تفاوت بین یک caller profile field (یا همان متغیرهای buil-in) و یک متغیر چنل است.

یک caller profile field شبیه به زیر قابل دسترسی می باشد :

<condition field="destination_number" attributes...> 

در حالی که یک متغیر چنلی به صورت زیر قابل دسترسی است :

<condition field="${sip_has_crypto}" attributes...> 

لطفا به نحوه استفاده از ${variable_name} توجه کنید. متغیرهای چنلی ممکن است در قسمت action هم استفاده شوند. علاوه بر این، فانکشن های API را می توان از درون یک عبارت شرطی فراخوانی کرد تا بتوان دیتای داینامیک تهیه کرد.

برای مثال شما میتوانید از cond API استفاده کنید :

<condition field="${cond(${my_var} > 12 ? YES : NO)}" expression="^YES$">
<action application="log" data="INFO ${my_var} is indeed greater than 12"/>
</condition> 

این مثال متغیر ${my_var} را تست میکند. اگر بیشتر از 12 باشد ،مقدار YES را برمیگرداند. درغیر اینصورت NO برگردانده می شود. عبارت شرطی نتایج را برای YES تست می کند و لاگها را به NSG log ارسال میکند.