Amir Jabbari
اگر سؤال شما این است که «برای سامانه تماس پرترافیک FreeSWITCH بهتر است یا Asterisk؟» پاسخ کوتاه این است: بدون Benchmark روی سناریوی واقعی خودتان، انتخاب قطعی قابل‌اعتماد نیست. هر دو می‌توانند هزاران Session یا Channel را در معماری درست مدیریت کنند، اما نوع بار تعیین می‌کند کدام‌یک برای شما مناسب‌تر است: تماس ساده بدون Transcoding، ضبط مکالمه، Conference، WebRTC، SRTP، AI Voice Bot، نرخ بالای ایجاد تماس یا Call Center هرکدام الگوی مصرف متفاوتی دارند.
نتیجه این مقاله: به‌جای تکرار جمله‌هایی مثل «FreeSWITCH ده‌هزار تماس می‌گیرد» یا «Asterisk فقط برای PBX کوچک است»، معیارهای قابل‌اندازه‌گیری می‌سازیم تا روی سخت‌افزار و Call Flow یکسان، هر دو موتور را منصفانه آزمایش کنید.
اول تفاوت Session، Channel و Call را روشن کنیم
بخش زیادی از مقایسه‌های اینترنتی از همین‌جا اشتباه می‌شوند. «۵۰۰ تماس» لزوماً به معنی «۵۰۰ Channel» یا «۵۰۰ Session» نیست.
در یک تماس Bridge شده معمولی، دو سمت تماس دارید: Leg ورودی و Leg خروجی. در FreeSWITCH هر Leg یک Session است؛ بنابراین ۵۰۰ تماس Bridge شده می‌تواند حدود ۱۰۰۰ Session ایجاد کند. در Asterisk نیز برای مقایسه ظرفیت باید تعداد Channelهای فعال را جدا از تعداد Callهای منطقی در نظر بگیرید.
پس در هر Benchmark، واحد را از ابتدا مشخص کنید:
🔹 Concurrent Calls: تعداد مکالمه‌های هم‌زمان واقعی.
🔹 Active Channels / Sessions: تعداد Legهای فعال داخل موتور.
🔹 CPS: تعداد Call Setup جدید در هر ثانیه.
🔹 RTP Streams: تعداد Streamهای صوتی یا تصویری عبوری.
وضعیت نسخه‌ها در اکتبر ۲۰۲۶
برای مقایسه عملی باید نسخه‌های واقعی و پشتیبانی‌شده را Benchmark کنید، نه Buildهای چندسال قبل.
| پلتفرم | نسخه مناسب مبنا | وضعیت |
|---|---|---|
| FreeSWITCH | 1.11.3 | Latest Release؛ منتشرشده ۲۸ اوت ۲۰۲۶ با اصلاحات امنیتی و پایداری |
| Asterisk | 22.11.0 | شاخه LTS و Fully Supported |
| Asterisk 23 | 23.5.0 | Standard Release؛ مناسب بررسی قابلیت‌های جدید ولی LTS نیست |
| Asterisk 24 | در اکتبر ۲۰۲۶ هنوز Release Candidate | برای Benchmark آزمایشی مناسب است، نه Baseline Production |
Asterisk 22 تا ۱۶ اکتبر ۲۰۲۸ Full Support و تا ۱۶ اکتبر ۲۰۲۹ Security Maintenance دارد. بنابراین برای مقایسه Production، شاخه 22 LTS مبنای منطقی‌تری از نسخه آزمایشی 24 است.
FreeSWITCH در بار بالا چگونه Media را مدیریت می‌کند؟
یکی از نقاط قوت معماری FreeSWITCH، کنترل صریح روی مسیر Media است. سه حالت اصلی دارد:
🔹 Normal Media: RTP هر دو Leg داخل FreeSWITCH Terminate می‌شود؛ Recording، Transcoding، DTMF Processing و Jitter Buffer ممکن است.
🔹 Proxy Media: RTP از سرور عبور می‌کند اما Payload Decode/Encode نمی‌شود.
🔹 Bypass Media: بعد از Signaling، Endpointها RTP را مستقیم به یکدیگر می‌فرستند و FreeSWITCH فقط Signaling را نگه می‌دارد.
همین تفاوت می‌تواند نتیجه Benchmark را چند برابر تغییر دهد. اگر یک تست FreeSWITCH را در Bypass Media و Asterisk را با Media Anchored مقایسه کند، نتیجه از پایه منصفانه نیست.
FreeSWITCH علاوه بر max-sessions، نرخ Session جدید را هم با sessions-per-second کنترل می‌کند. در تنظیمات Core، Defaultهای مستند فعلی ۱۰۰۰ Session و ۳۰ Session در ثانیه هستند؛ این اعداد سقف سخت‌افزار نیستند، بلکه Limitهای Config هستند و باید برای Benchmark آگاهانه تنظیم شوند.
<param name="max-sessions" value="2000"/>
<param name="sessions-per-second" value="100"/>این فقط نمونه است؛ عدد درست باید بعد از Load Test تعیین شود.
Asterisk در بار بالا چه چیزی را باید مراقبت کنید؟
در Asterisk نیز اگر دو سمت تماس از Codec یکسان استفاده کنند و فقط Media Forward شود، هزینه CPU نسبتاً پایین است. مستند رسمی Asterisk صراحتاً می‌گوید معمولاً بزرگ‌ترین مصرف CPU زمانی رخ می‌دهد که Media نیاز به Transcoding دارد.
این موضوع فقط تبدیل G.711 به Opus یا G.729 نیست. پخش Prompt، Music on Hold، Recording و Voicemail نیز می‌توانند باعث Translation یا Media Processing شوند.
برای دیدن هزینه Codecها روی همان CPU:
core show translation recalc 60Asterisk همچنین direct_media دارد و می‌تواند در سناریوهای مناسب RTP را مستقیماً بین Endpointها برقرار کند. بنابراین همان قانون مقایسه FreeSWITCH اینجا هم صدق می‌کند: Media Path باید در هر دو تست یکسان باشد.
پس کدام‌یک برای Concurrency بالا بهتر است؟
Concurrency به‌تنهایی معیار انتخاب نیست. سؤال درست این است: «در چه Call Flow و با چه Media Workload؟»
| سناریو | FreeSWITCH | Asterisk | نکته تصمیم |
|---|---|---|---|
| SIP Signaling با Bypass Media | بسیار مناسب | بسیار مناسب | CPS و Signaling Path مهم‌تر از Codec است |
| RTP Anchored بدون Transcoding | مناسب | مناسب | NIC، Kernel، Packet Rate و Logging مهم‌اند |
| Transcoding سنگین | قوی و Media-oriented | قابل انجام؛ CPU را دقیق Benchmark کنید | Codec Matrix تعیین‌کننده است |
| Conference پرتعداد | معمولاً انتخاب طبیعی‌تر | قابل‌پیاده‌سازی | Mixing، Sample Rate و Recording را تست کنید |
| WebRTC Browser | SIP/WSS و Verto | PJSIP/WSS + WebRTC | ICE، DTLS-SRTP، Opus و TURN مهم‌اند |
| PBX سازمانی سنتی | خوب | اکوسیستم بسیار گسترده | GUI و Integrationهای موجود مهم‌تر از Raw Throughput است |
| Call Control API | Event Socket | ARI/AMI/AGI | تجربه تیم توسعه تعیین‌کننده است |
| Hosted PBX / Multi-tenant | اکوسیستم FusionPBX و طراحی FreeSWITCH مناسب است | با پلتفرم‌های بالادستی و معماری جدا قابل انجام است | Isolation و Billing را جدا Benchmark کنید |
WebRTC؛ FreeSWITCH یا Asterisk؟
هر دو WebRTC را پشتیبانی می‌کنند، اما مسیرشان کمی متفاوت است.
FreeSWITCH دو مدل اصلی دارد: SIP over WSS از طریق mod_sofia و Verto از طریق mod_verto. Verto یک پروتکل JSON-RPC برای WebRTC است و Media از DTLS-SRTP و ICE استفاده می‌کند.
Asterisk نیز PJSIP over WebSocket/WSS، DTLS-SRTP، ICE و Opus را پشتیبانی می‌کند. مستند رسمی برای WebRTC استفاده از res_http_websocket، res_pjsip_transport_websocket و PJSIP Endpoint را توضیح می‌دهد.
برای Benchmark WebRTC فقط تعداد Call را اندازه نگیرید. این موارد را هم ثبت کنید:
🔹 زمان ICE Completion.
🔹 DTLS Handshake Time.
🔹 مصرف CPU با Opus.
🔹 Packet Loss و Jitter در SRTP.
🔹 درصد Callهایی که به TURN Relay می‌روند.
🔹 Memory Growth در اتصال‌های WSS طولانی.
اکوسیستم؛ جایی که Asterisk معمولاً مزیت عملیاتی دارد
Asterisk سال‌هاست پایه تعداد زیادی PBX و سیستم سازمانی است. FreePBX، VitalPBX و مجموعه بزرگی از ابزارهای Provisioning، Monitoring و Integration روی آن شکل گرفته‌اند.
در سمت توسعه هم سه رابط معروف دارید:
🔹 AMI: Event-driven برای مدیریت و مشاهده وضعیت.
🔹 AGI/FastAGI: اتصال Dialplan به برنامه خارجی.
🔹 ARI: REST + WebSocket برای ساخت Applicationهای Call Control.
در نسخه‌های جدید Asterisk، ARI حتی قابلیت Outbound WebSocket و سناریوهای ساده‌تر Load Balancing/Failure Recovery برای Application Serverها را هم توسعه داده است.
این مزیت لزوماً به معنی Throughput بالاتر نیست؛ یعنی ممکن است برای تیم شما هزینه توسعه، نگهداری و مانیتورینگ کمتر شود.
اکوسیستم FreeSWITCH؛ تمرکز بیشتر روی Media و Integration
FreeSWITCH تقریباً همه قابلیت‌ها را به‌صورت Module ارائه می‌کند. SIP با mod_sofia، WebRTC با mod_verto/mod_rtc، Conference با mod_conference و Integration خارجی با mod_event_socket انجام می‌شود.
Event Socket می‌تواند از یک Application خارجی Command و Event بگیرد و برای معماری‌هایی که Control Plane جدا از Media Server دارند مناسب است.
اگر پروژه شما Media Server، Conference، Gateway، WebRTC Edge یا Programmable Telecom است، همین ساختار ماژولار معمولاً با معماری پروژه هم‌راستاتر است.
HA؛ هیچ‌کدام را با «یک سرور خیلی قوی» High Availability نکنید
HA واقعی با یک Process یا یک VPS ساخته نمی‌شود. اگر کل تماس‌های شما روی یک Node باشند، خرابی همان Node می‌تواند همه Sessionهای Active را قطع کند؛ حتی اگر Configuration Backup داشته باشید.
برای هر دو پلتفرم بهتر است HA را لایه‌ای طراحی کنید:
🔹 SIP Proxy/Load Balancer در Edge؛ مثل Kamailio یا OpenSIPS.
🔹 حداقل دو Media/PBX Node.
🔹 Health Check فعال برای Nodeها.
🔹 Database/Config Replication متناسب با Application.
🔹 DNS/SRV یا Proxy Routing برای ورودی‌ها.
🔹 Storage و Recording مستقل از یک Node.
در اینجا باید دو شاخص را جدا کنید: Failover تماس جدید و Survival تماس در حال اجرا. بسیاری از معماری‌های Active/Standby فقط تماس‌های جدید را به Node سالم هدایت می‌کنند؛ تماس‌های Active روی Node خراب‌شده الزاماً زنده نمی‌مانند.
Benchmark واقعی باید چه چیزهایی را ثابت نگه دارد؟
اگر می‌خواهید نتیجه علمی باشد، این متغیرها در تست FreeSWITCH و Asterisk باید یکسان باشند:
🔹 یک CPU Model و تعداد vCPU یکسان.
🔹 یک Hypervisor و Storage Class یکسان.
🔹 یک Kernel و Network MTU یکسان.
🔹 یک Codec و Packetization Time یکسان.
🔹 Media Mode یکسان: Anchored یا Direct/Bypass.
🔹 TLS/SRTP یا Plain RTP یکسان.
🔹 Logging Level یکسان و Debug خاموش.
🔹 Recording یا Conference دقیقاً یکسان.
🔹 Generator روی سرور جدا تا خود Generator Bottleneck نشود.
معیارهای قابل‌اندازه‌گیری که باید ثبت کنید
| Metric | چرا مهم است؟ |
|---|---|
| Maximum Sustained Concurrent Calls | ظرفیت واقعی قبل از افت کیفیت |
| CPS پایدار | توان Call Setup در Burst و کمپین |
| P50/P95/P99 Call Setup Time | کندشدن Signaling قبل از Crash را نشان می‌دهد |
| Failed Call Ratio | 503/408/Timeout و Failure واقعی |
| CPU User/System/Steal | تفکیک محدودیت Application از Hypervisor |
| RSS Memory | Memory Footprint و Leak احتمالی |
| Packets/sec | فشار Kernel/NIC در RTP زیاد |
| Packet Loss/Jitter | کیفیت Media زیر Load |
| Disk Write Latency | برای Recording و CDR حیاتی است |
| Transcoding Cost | اثر Codec Conversion روی CPU |
| Recovery Time | رفتار HA و Failover |
SIPp؛ ابزار مناسب برای Load Test قابل‌تکرار
SIPp به‌صورت مشخص برای SIP Performance Testing ساخته شده و می‌تواند نرخ Call بالا، تعداد Call هم‌زمان و Response Time را اندازه‌گیری کند. برای تست Performance، Documentation خود SIPp توصیه می‌کند Traceهای سنگین را خاموش کنید تا Generator خودش Bottleneck نشود.
نمونه تست ساده با نرخ ۲۰ Call در ثانیه و حداکثر ۵۰۰ Call هم‌زمان:
sipp 203.0.113.10:5060 \
-sf uac.xml \
-r 20 \
-rp 1000 \
-l 500 \
-m 10000 \
-trace_rttبرای تست جدی، سناریو XML باید دقیقاً Call Flow واقعی شما را تقلید کند: 100 Trying، 180/183، 200 OK، ACK، Hold Time، BYE و در صورت نیاز RTP/SRTP.
اشتباه رایج: SIPp را روی همان VPS که Asterisk یا FreeSWITCH اجرا می‌شود نصب نکنید و بعد از نتیجه CPU نتیجه‌گیری نکنید. Generator باید روی Host جدا باشد، و برای Load خیلی بالا بهتر است چند Generator داشته باشید.
چهار سناریوی Benchmark که واقعاً ارزش دارند
تست ۱: Signaling Only
Media را Direct/Bypass کنید و فقط SIP Setup را فشار دهید. این تست برای سنجش CPS، Parser، Dialplan و Control Plane است.
تست ۲: RTP Anchored بدون Transcoding
G.711 ↔ G.711 با Media داخل سرور. این تست NIC، Packet Rate، RTP Stack و Kernel را نشان می‌دهد.
تست ۳: Transcoding واقعی
مثلاً Opus ↔ G.711. در این مرحله انتظار دارید CPU سریع‌تر بالا برود. نتیجه این تست را نمی‌توان از تست Signaling حدس زد.
تست ۴: Production Features
Recording، TLS، SRTP، CDR، WebRTC، Queue یا Conference را دقیقاً مثل Production فعال کنید. عددی که از این تست می‌گیرید از نظر Capacity Planning مهم‌تر از «حداکثر تماس خام» است.
هنگام Benchmark خود موتور را هم مانیتور کنید
FreeSWITCH
fs_cli -x "status"
fs_cli -x "show channels count"
fs_cli -x "show calls"خروجی status علاوه بر Session فعلی، Peak و Sessions per Second را نشان می‌دهد.
Asterisk
asterisk -rx "core show channels count"
asterisk -rx "core show taskprocessors"
asterisk -rx "core show translation recalc 60"Linux
pidstat -u -r -p $(pidof freeswitch) 1
sar -n DEV 1
vmstat 1برای Asterisk فقط نام Process را عوض کنید:
pidstat -u -r -p $(pidof asterisk) 1Logging می‌تواند نتیجه Benchmark را خراب کند
Asterisk در مستند Performance خودش هشدار می‌دهد Logging و مخصوصاً Verbose/Debug می‌تواند هزینه قابل‌توجهی ایجاد کند. حتی در نسخه‌های قدیمی‌تر، Channel Event Logging سهم بسیار بزرگی از Instructionهای CPU داشت و در نسخه‌های جدید بهینه‌سازی شده است.
در FreeSWITCH هم Debug Logging پرحجم باعث CPU و Disk I/O اضافی می‌شود.
بنابراین در تست Capacity:
🔹 Debug SIP Trace فقط برای عیب‌یابی کوتاه‌مدت روشن باشد.
🔹 Log Level در هر دو موتور مشابه باشد.
🔹 Packet Capture کامل روی سرور تحت تست اجرا نشود؛ Capture را روی Mirror/TAP یا Node جدا انجام دهید.
🔹 CDR/CEL را دقیقاً مطابق Production روشن یا خاموش کنید.
برای AI Voice Bot کدام مناسب‌تر است؟
در پروژه AI Voice Bot، فقط SIP مهم نیست. Audio باید از Media Engine به STT/LLM/TTS یا Media Service خارجی برسد.
Asterisk در نسخه‌های جدید Channel Driver مبتنی بر WebSocket برای Media دارد که انتقال Audio به Application خارجی را ساده‌تر می‌کند و با ARI ExternalMedia قابل استفاده است. این قابلیت در شاخه 22 از نسخه 22.6 در دسترس است.
FreeSWITCH نیز با Event Socket، Modules و Media Architecture منعطف، گزینه مناسبی برای Voice Applicationهای سفارشی است.
در این سناریو Benchmark مهم باید شامل این موارد باشد: Latency رفت‌وبرگشت Audio، Backpressure، تعداد Streamهای هم‌زمان، Codec Conversion و رفتار سیستم هنگام کندشدن سرویس AI.
مطلب مرتبط: اگر هدف شما اتصال تماس به مدل گفتاری و AI است، راهنمای ایجنت تلفنی هوش مصنوعی روی VPS را هم ببینید.
روش تصمیم‌گیری پیشنهادی
| اگر اولویت اصلی شماست… | از این گزینه شروع کنید |
|---|---|
| Media Server، Conference، WebRTC یا RTP Processing سنگین | FreeSWITCH را اول Benchmark کنید |
| PBX سازمانی با اکوسیستم آماده و GUIهای متعدد | Asterisk را اول Benchmark کنید |
| Application تلفنی با ARI/AMI و Integration زیاد | Asterisk جذاب‌تر است |
| Hosted PBX مبتنی بر FreeSWITCH | FreeSWITCH/FusionPBX طبیعی‌تر است |
| SIP Signaling بسیار پرترافیک بدون Media | هر دو را تست کنید؛ شاید Proxy/SBC اختصاصی نیز لازم باشد |
| ده‌ها هزار Endpoint یا Carrier-grade Edge | فقط یک PBX کافی نیست؛ Proxy/SBC + چند Media Node طراحی کنید |
برای سامانه واقعاً پرترافیک، انتخاب اصلی اغلب دیگر «FreeSWITCH یا Asterisk» نیست؛ انتخاب مهم‌تر معماری Cluster است. یک SIP Proxy در Edge، چند Node مستقل، Load Balancing، Health Check و Storage جدا می‌توانند بیشتر از تفاوت خام دو موتور روی Availability اثر بگذارند.
چک‌لیست قبل از انتخاب نهایی
🔹 Peak Concurrent Call واقعی را از CDR قبلی یا Forecast مشخص کنید.
🔹 CPS در Busy Hour را اندازه بگیرید.
🔹 Codec Matrix را مشخص کنید؛ مخصوصاً Opus/G.711/G.729.
🔹 Recording، Conference و WebRTC را از Benchmark حذف نکنید اگر در Production دارید.
🔹 تست را حداقل چند ده دقیقه در Steady State نگه دارید.
🔹 CPU Steal روی VPS را هم ثبت کنید.
🔹 Failure Test انجام دهید؛ فقط Capacity Test کافی نیست.
🔹 نتیجه را بر اساس Cost per Sustained Call هم مقایسه کنید.
می‌خواهید FreeSWITCH و Asterisk را روی VPS واقعی مقایسه کنید؟
بهترین روش این است که دو VPS با CPU، RAM و Network یکسان بسازید، Call Flow یکسان را روی هر دو اجرا کنید و با SIPp نرخ تماس را مرحله‌به‌مرحله افزایش دهید. بعد CPU، Memory، Call Setup Time، Failure Rate و RTP Quality را مقایسه کنید.
ایرانیکاسرور می‌تواند برای آماده‌سازی VPS آزمایشی، نصب Asterisk یا FreeSWITCH و طراحی تست اولیه زیرساخت کمک کند.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
پرسش‌های رایج
FreeSWITCH از Asterisk تماس هم‌زمان بیشتری می‌گیرد؟
هیچ عدد عمومی قابل‌اعتمادی برای همه سناریوها وجود ندارد. ظرفیت به CPU، Codec، Transcoding، Media Path، Recording، TLS/SRTP، Logging و Call Flow بستگی دارد. برای تصمیم واقعی باید هر دو روی شرایط یکسان Benchmark شوند.
FreeSWITCH برای Media سنگین بهتر است؟
معماری FreeSWITCH کنترل گسترده‌ای روی Normal، Proxy و Bypass Media، Conference و WebRTC دارد و برای پروژه‌های Media-oriented نقطه شروع مناسبی است؛ اما ظرفیت واقعی همچنان باید اندازه‌گیری شود.
بزرگ‌ترین عامل مصرف CPU در Asterisk چیست؟
طبق مستند Performance Asterisk، Media Processing و به‌خصوص Transcoding معمولاً یکی از مهم‌ترین مصرف‌کننده‌های CPU است. Logging سنگین نیز می‌تواند اثر قابل‌توجهی داشته باشد.
هر دو WebRTC دارند؟
بله. FreeSWITCH هم SIP over WSS و هم Verto دارد. Asterisk نیز PJSIP over WebSocket/WSS با ICE و DTLS-SRTP را پشتیبانی می‌کند.
برای HA کدام بهتر است؟
HA را نباید فقط به موتور PBX وابسته کرد. در بار بالا بهتر است SIP Proxy/Load Balancer، چند Node و Health Check داشته باشید. Failover تماس جدید با حفظ تماس Active دو مسئله جدا هستند.
برای Benchmark از چه ابزاری استفاده کنیم؟
SIPp یکی از ابزارهای استاندارد برای تولید SIP Load و اندازه‌گیری Call Rate و Response Time است. Generator باید روی ماشین جدا اجرا شود.
CPS مهم‌تر است یا Concurrent Call؟
هر دو مهم‌اند. Concurrent Call ظرفیت Steady State را نشان می‌دهد و CPS توان سیستم هنگام Burst و ایجاد تماس جدید را. سامانه کمپین Outbound ممکن است CPS بالا ولی Duration کوتاه داشته باشد.
برای یک Call Center معمولی کدام را انتخاب کنیم؟
اگر اکوسیستم PBX، Queue و Integration آماده اولویت اصلی است، Asterisk معمولاً مسیر ساده‌تری دارد. اگر Media Server، Conference یا WebRTC بخش غالب پروژه است، FreeSWITCH را جدی‌تر Benchmark کنید.
جمع‌بندی
برای سامانه تماس پرترافیک، FreeSWITCH و Asterisk را با شعار انتخاب نکنید. FreeSWITCH در معماری Media-oriented، Conference و WebRTC ابزارهای بسیار قدرتمندی دارد و Asterisk در اکوسیستم PBX، PJSIP و Interfaceهای برنامه‌نویسی مثل ARI/AMI جایگاه بسیار قوی دارد.
تفاوت اصلی زمانی مشخص می‌شود که بار واقعی خودتان را وارد کنید. G.711 بدون Transcoding، Opus Transcoding، Recording، SRTP، Conference و WebRTC هرکدام نتیجه متفاوتی می‌سازند.
یک Benchmark معتبر باید نسخه، سخت‌افزار، Media Path، Codec، Logging و Call Flow یکسان داشته باشد و حداقل Concurrent Calls، CPS، P95/P99 Setup Time، Failure Rate، CPU، Memory، Network و Packet Loss را ثبت کند.
برای پروژه‌های بسیار بزرگ نیز به‌جای یک PBX غول‌پیکر، معماری چندلایه با SIP Proxy، چند Media Node و Failover طراحی کنید. در آن مقیاس، معماری سیستم بیشتر از نام موتور تعیین می‌کند که سرویس در Busy Hour پایدار بماند یا نه.
برای Load Test Asterisk و FreeSWITCH کمک می‌خواهید؟
اگر تعداد تماس هم‌زمان، CPS، Codec و نیاز به Recording/WebRTC مشخص باشد، می‌توان دو VPS یکسان ساخت و یک Test Plan قابل‌تکرار برای مقایسه هر دو موتور اجرا کرد.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
دیدگاه‌ها (۰)