چطور تلفن‌های Yealink، Cisco و Fanvil را به‌صورت مرکزی مدیریت کنیم؟

Provisioning مرکزی یعنی تلفن‌های Yealink، Cisco و Fanvil به‌جای تنظیم دستی، فایل تنظیمات و Firmware خود را از یک سرور مشترک دریافت کنند. در یک شبکه کوچک شاید تنظیم ۱۰ تلفن با Web UI قابل‌تحمل باشد، اما وقتی صدها گوشی، چند شعبه و چند مدل مختلف دارید، تغییر SIP Server، رمز داخلی، VLAN، NTP، DSS Key یا Firmware به‌صورت دستی هم زمان‌بر است و هم احتمال خطای انسانی را بالا می‌برد.

راه درست این است که یک VoIP Phone Provisioning Server بسازید که برای هر Vendor قالب مخصوص خودش را نگه دارد، برای هر MAC فایل اختصاصی تولید کند، Secretها را از Template جدا نگه دارد، فایل‌ها را از طریق HTTPS تحویل دهد و Firmware را به‌صورت مرحله‌ای روی Ringهای آزمایشی و Production منتشر کند.

این مقاله معماری را Vendor-neutral طراحی می‌کند، اما تفاوت واقعی سه خانواده مهم را هم جدا توضیح می‌دهد: Yealink با Common و MAC-Oriented CFG، Cisco MPP با Profile Rule و Macroها، و Fanvil با Common/Device Config و Auto Provision. هدف این است که یک سرور داشته باشید، نه سه سیستم مدیریتی جدا.

Provisioning مرکزی دقیقاً چه چیزی را مدیریت می‌کند؟

Provisioning Server فقط محل فایل SIP Account نیست. در طراحی درست می‌تواند تقریباً تمام تنظیمات قابل‌Provision تلفن را کنترل کند:

اما هر Vendor نام Parameter، Format فایل و ترتیب Apply متفاوتی دارد؛ بنابراین یک Template واحد برای همه برندها اشتباه است. چیزی که باید مشترک باشد Data Model و Workflow است، نه Syntax فایل.

معماری پیشنهادی یک Provisioning Server چندبرندی

                    Inventory / Database
                vendor, model, MAC, extension
                         firmware_ring
                               |
                               v
                     Template Renderer
                  /         |          \\
                 /          |           \\
          Yealink         Cisco        Fanvil
          templates       MPP XML      templates
                 \\          |           /
                  \\         |          /
                   +--------+---------+
                            |
                       HTTPS Server
                            |
         +------------------+------------------+
         |                  |                  |
         v                  v                  v
      Yealink             Cisco              Fanvil
      Phones              MPP Phones         Phones

در این مدل، Database می‌داند هر MAC چه Vendor و Modelی دارد. Renderer بر اساس همین اطلاعات Template مناسب را می‌سازد. Server فایل خام مشترک برای همه گوشی‌ها منتشر نمی‌کند؛ هر Device فقط فایل‌هایی را می‌بیند که برای خودش لازم است.

Data Model را قبل از Templateها طراحی کنید

اگر اطلاعات تلفن‌ها را داخل خود فایل‌های Vendor نگه دارید، خیلی زود سیستم غیرقابل‌مدیریت می‌شود. بهتر است Inventory مستقل داشته باشید:

device:
  id: 1042
  vendor: yealink
  model: T54W
  mac: 001565A1B2C3
  site: tehran-office
  extension: 204
  auth_user: 204
  secret_ref: vault://sip/204
  firmware_ring: pilot
  template_version: 17
  enabled: true

نکته مهم این است که secret_ref به Secret اشاره می‌کند؛ Password را داخل Inventory Export، Git یا Template Repository ننویسید.

Yealink؛ Common CFG و فایل مخصوص MAC

Yealink در مستند فعلی خود دو نوع فایل اصلی را توضیح می‌دهد: Common CFG برای تنظیمات مشترک یک مدل و MAC-Oriented CFG برای تنظیمات مخصوص یک دستگاه. فایل MAC-Oriented با MAC دوازده‌رقمی تلفن نام‌گذاری می‌شود و برای مواردی مثل Registration مناسب است.

نمونه ساختار:

/provision/yealink/
├── y000000000096.cfg
├── y000000000097.cfg
├── 001565a1b2c3.cfg
├── 001565d4e5f6.cfg
└── firmware/
    ├── T54W/
    └── T57W/

نام Common CFG وابسته به Model است؛ بنابراین شماره نمونه بالا را برای مدل دیگر کپی نکنید. Yealink Template رسمی همان Model را مبنا قرار دهید.

نمونه MAC-Oriented CFG

#!version:1.0.0.1

account.1.enable = 1
account.1.label = 204
account.1.display_name = Support-204
account.1.auth_name = 204
account.1.user_name = 204
account.1.password = __DEVICE_SECRET__
account.1.sip_server.1.address = sip.example.com
account.1.sip_server.1.port = 5061
account.1.transport = 2

این فقط مثال ساختار است. Parameterها را برای Firmware و Model واقعی از Administrator Guide همان تلفن بگیرید. Yealink همچنین تأکید می‌کند Header فایل و Syntax باید درست باشد؛ در غیر این صورت فایل دانلود می‌شود ولی Apply نمی‌شود.

HTTPS و Encryption در Yealink

Yealink برای Provisioning از TFTP، FTP/FTPS، HTTP و HTTPS پشتیبانی می‌کند و Configuration File Encryption هم دارد. در طراحی جدید، HTTPS را Baseline قرار دهید و برای فایل‌هایی که SIP Secret دارند، Encryption Vendor را هم در صورت سازگاری Model/Firmware فعال کنید.

مستند Yealink امکان AES Key جدا برای Common و MAC-Oriented Configuration را توضیح می‌دهد. یعنی حتی اگر فایل Provisioning از Storage لو رفت، Secretها الزاماً Plaintext نیستند.

Cisco؛ MPP را با Enterprise Firmware اشتباه نگیرید

برای Provisioning مستقل، معمولاً منظور Cisco Multiplatform Phone یا MPP است. تلفن‌هایی که Firmware سازمانی مخصوص CUCM دارند دقیقاً همان Provisioning Model را ندارند. قبل از طراحی Template مطمئن شوید Device واقعاً روی MPP Firmware است.

Cisco MPP از Profile_Rule و Macro Expansion برای ساخت URL اختصاصی Device استفاده می‌کند. Cisco در مثال رسمی از Macro مربوط به MAC برای فایل Per-Device استفاده کرده است.

https://prov.example.com/cisco/$MA.cfg

برای یک Device با MAC مشخص، Macro هنگام Resync به فایل همان گوشی تبدیل می‌شود.

Cisco MPP و HTTPS Resync

Cisco در Provisioning Guide برای MPP، HTTPS Resync، Client Certificate Authentication و Client Filtering را مستند کرده است. این یعنی برای ناوگان حساس می‌توانید فقط Encryption Transport نداشته باشید، بلکه Device را هم در سمت Server احراز هویت کنید.

ساختار پیشنهادی:

/provision/cisco/
├── common/
│   ├── 68xx-base.xml
│   └── 88xx-base.xml
├── devices/
│   ├── 000E08123456.xml
│   └── 000E08654321.xml
└── firmware/
    ├── 6800/
    └── 8800/

در Cisco هم Template را از Data جدا نگه دارید. XML یا Profile نهایی باید توسط Renderer ساخته شود و Credential داخل Repository باقی نماند.

Fanvil؛ Common Config و Device Config

Fanvil نیز Auto Provision را با SIP PnP، DHCP Option، Static Provisioning و TR-069 پشتیبانی می‌کند. انتقال فایل می‌تواند با FTP، TFTP، HTTP و HTTPS انجام شود.

در مستند فعلی Fanvil، اگر نام Configuration File خالی باشد، Device می‌تواند Common File و فایل Device-specific بر اساس MAC را درخواست کند. در Static Provision نیز نام‌هایی مانند $mac.cfg و فرمت‌های CFG/TXT/XML مستند شده‌اند.

ساختار پیشنهادی:

/provision/fanvil/
├── common/
│   ├── x4u.cfg
│   └── x5u.cfg
├── devices/
│   ├── 0c383e45f468.cfg
│   └── 0c383e45f469.cfg
└── firmware/
    ├── X4U/
    └── X5U/

Fanvil برای Authentication Server و همچنین Encryption Key فایل Configuration گزینه دارد. مستند رسمی Encryption نیز اشاره می‌کند فایل Provisioning ممکن است SIP Password و Admin Password داشته باشد و برای جلوگیری از Leakage می‌توان آن را Encrypt کرد.

یک Template مشترک نسازید؛ یک Data Model مشترک بسازید

این اشتباه رایج است:

one-template.cfg
  |
  +--> Yealink
  +--> Cisco
  +--> Fanvil

روش درست:

shared device data
        |
        +--> yealink/template.j2
        |
        +--> cisco/template.xml.j2
        |
        +--> fanvil/template.j2

Data مشترک است: Extension، Secret، SIP Server، VLAN، NTP و Ring. Syntax خروجی Vendor-specific است.

ساختار Directory پیشنهادی

/srv/phone-provisioning/
├── templates/
│   ├── yealink/
│   ├── cisco/
│   └── fanvil/
├── rendered/
│   ├── yealink/
│   ├── cisco/
│   └── fanvil/
├── firmware/
│   ├── yealink/
│   ├── cisco/
│   └── fanvil/
├── metadata/
│   └── devices.db
└── releases/
    ├── lab/
    ├── pilot/
    └── production/

Templateها می‌توانند در Git باشند، اما rendered files دارای Secret نباید وارد Git شوند.

Nginx را فقط به‌عنوان لایه تحویل فایل استفاده کنید

یک الگوی ساده HTTPS:

server {{
    listen 443 ssl http2;
    server_name prov.example.com;

    ssl_certificate     /etc/letsencrypt/live/prov.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/prov.example.com/privkey.pem;

    autoindex off;

    location /phones/ {{
        alias /srv/phone-provisioning/rendered/;
        default_type application/octet-stream;

        add_header Cache-Control "no-store";
        try_files $uri =404;
    }}

    location /firmware/ {{
        alias /srv/phone-provisioning/firmware/;
        default_type application/octet-stream;
        autoindex off;
    }}

    access_log /var/log/nginx/provision-access.log;
    error_log  /var/log/nginx/provision-error.log;
}}

برای Production بهتر است Device Configها مستقیماً از یک Public Directory ساده سرو نشوند. Application Layer می‌تواند MAC/Token/Client Certificate را اعتبارسنجی کند و سپس فایل Renderشده را تحویل دهد.

MAC Address به‌تنهایی Secret نیست

نام فایل MAC-Based برای Provisioning بسیار رایج است، اما MAC Address را نباید Authentication Token فرض کنید. MAC قابل حدس، مشاهده و Enumerate است.

این URL به‌تنهایی امن نیست:

https://prov.example.com/001565a1b2c3.cfg

اگر فایل شامل SIP Password باشد، کسی که URL را حدس بزند ممکن است Credential را دانلود کند.

لایه‌های بهتر:

Secretها را از Template جدا کنید

Template Repository باید بتواند Public باشد بدون اینکه Credential تلفن‌ها را افشا کند. Template:

account.username = {{ extension }}
account.password = {{ sip_secret }}
sip.server = {{ sip_server }}

Renderer در زمان ساخت فایل مقدار sip_secret را از Secret Store می‌خواند. فایل نهایی بهتر است عمر کوتاه در Cache داشته باشد و Permission فایل محدود باشد.

نمونه Permission:

chown -R provapp:www-data /srv/phone-provisioning
chmod 750 /srv/phone-provisioning
chmod 750 /srv/phone-provisioning/rendered

Permission واقعی را با معماری Process خودتان تنظیم کنید؛ هدف این است که همه Userهای سیستم نتوانند Configهای دارای Password را بخوانند.

Provisioning Server Address را تلفن چطور پیدا می‌کند؟

روش Discovery بین Vendorها متفاوت است. گزینه‌های رایج عبارت‌اند از:

Yealink در مستند فعلی از DHCP Option 66 و PnP برای کشف Provisioning Server پشتیبانی می‌کند. Fanvil هم SIP PnP، DHCP، Static Provision و TR-069 را مستند کرده است. Cisco MPP نیز Profile Rule و روش‌های DHCP/Redirect خاص خود را دارد.

Firmware Ring؛ همه گوشی‌ها را یک‌باره Upgrade نکنید

مهم‌ترین قابلیت Provisioning Server حرفه‌ای، فقط Push کردن Firmware نیست؛ کنترل Blast Radius است.

Ring پیشنهادی:

LAB
  2-5 phones
      |
      v
PILOT
  5-10% of fleet
      |
      v
PRODUCTION-A
  30%
      |
      v
PRODUCTION-B
  remaining fleet

هر Device در Inventory یک firmware_ring دارد. Template Renderer بر اساس Vendor، Model و Ring، Firmware URL مناسب را داخل Config قرار می‌دهد.

چرا Ring لازم است؟

Firmware ممکن است روی یک Model سالم باشد ولی روی Revision دیگر مشکل Headset، BLF، TLS، VLAN یا Registration ایجاد کند. Pilot باید ترکیبی واقعی از مدل‌ها و Siteها باشد، نه فقط یک گوشی روی میز مدیر شبکه.

Cisco Upgrade Rule، Yealink Firmware و Fanvil Version را جدا مدیریت کنید

Cisco MPP در مستند جدید خود Upgrade_Rule را برای Firmware URL و شرط‌های Upgrade تعریف می‌کند. Yealink Firmware Provisioning و Fanvil Version/Auto Provision Syntax ساختار خودشان را دارند.

بنابراین Metadata مشترک شما باید مثلاً این باشد:

firmware_policy:
  vendor: cisco
  model: CP-8841-3PCC
  ring: pilot
  target_version: 12.x.y
  artifact: firmware/cisco/8841/...
  checksum: sha256:...
  approved_at: 2026-10-20

سپس Vendor Renderer این Policy را به Syntax همان Vendor تبدیل می‌کند.

Firmware را بر اساس Model و Hardware Variant جدا کنید

یک Directory مشترک با نام latest.bin برای همه تلفن‌ها خطرناک است. Artifact باید حداقل با Vendor، Model و Variant جدا شود.

/firmware/
├── yealink/
│   ├── T54W/
│   └── T57W/
├── cisco/
│   ├── CP-8841-3PCC/
│   └── CP-8851-3PCC/
└── fanvil/
    ├── X4U/
    └── X5U/

در Cisco به تفاوت MPP/3PCC با Enterprise Firmware حساس باشید. در هیچ Vendorی Firmware یک Model را فقط به‌خاطر شباهت نام روی Model دیگر Push نکنید.

Rollback را قبل از Upgrade طراحی کنید

Rollback یعنی فقط فایل قبلی را نگه ندارید؛ باید بدانید Device واقعاً Downgrade را قبول می‌کند یا نه. بعضی Firmwareها به‌دلیل Bootloader، Security Policy یا Migration Schema Downgrade محدود دارند.

برای هر Release ثبت کنید:

قبل از Production، Upgrade و Rollback را روی همان Model و Hardware Revision تست کنید.

Audit؛ بدانید هر تلفن آخرین بار چه فایلی گرفته است

بدون Audit، وقتی یک گوشی تنظیم متفاوت دارد نمی‌دانید مشکل از Template، Cache، Firmware یا Provisioning Trigger بوده است.

حداقل این Eventها را ذخیره کنید:

timestamp
device_mac
vendor
model
requested_path
template_version
firmware_ring
http_status
source_ip
user_agent
response_bytes

در Log، SIP Password یا Authorization Header را ذخیره نکنید.

Health Check برای Provisioning Server

Provisioning Server اگر Down باشد ممکن است گوشی‌های موجود همچنان تماس بگیرند، اما Device جدید، Factory Reset، تغییر Password یا Upgrade Firmware متوقف می‌شود.

Health Check پیشنهادی:

امنیت Server؛ Checklist کوتاه

اشتباه‌های رایج در Provisioning چندبرندی

پرسش‌های رایج

آیا Yealink، Cisco و Fanvil می‌توانند از یک Provisioning Server استفاده کنند؟

بله. سرور HTTPS می‌تواند مشترک باشد، اما Template، File Naming، Parameterها و Firmware هر Vendor باید جدا مدیریت شوند.

Yealink فایل مخصوص هر تلفن را چگونه می‌خواند؟

Yealink از MAC-Oriented CFG استفاده می‌کند؛ فایل با MAC دوازده‌رقمی Device نام‌گذاری می‌شود و برای تنظیماتی مثل SIP Registration مناسب است.

Cisco MPP فایل Per-Device را چطور پیدا می‌کند؟

Profile Rule می‌تواند Macroهایی مانند MAC Address را داخل URL Expand کند و Device فایل اختصاصی خودش را هنگام Resync درخواست کند.

Fanvil از HTTPS Provisioning پشتیبانی می‌کند؟

بله. مستند فعلی Fanvil، FTP، TFTP، HTTP و HTTPS را برای Auto Provision پشتیبانی‌شده اعلام می‌کند.

آیا MAC Address برای محافظت از Config کافی است؟

خیر. MAC Secret نیست. برای فایل‌های دارای Password از HTTPS، Authentication، Client Certificate یا Encryption فایل در Deviceهای سازگار استفاده کنید.

Firmware Ring چیست؟

گروه‌بندی Deviceها برای Rollout مرحله‌ای Firmware است؛ مثلاً Lab، Pilot و Production. هدف این است که Firmware خراب تمام تلفن‌ها را هم‌زمان تحت‌تأثیر قرار ندهد.

آیا Secretها را می‌توان داخل Template ذخیره کرد؟

بهتر است نه. Template فقط Placeholder داشته باشد و Renderer Secret را هنگام ساخت فایل از Secret Store یا Database امن دریافت کند.

آیا برای Provisioning هنوز TFTP مناسب است؟

در LAN کنترل‌شده ممکن است تجهیزات قدیمی هنوز از آن استفاده کنند، اما برای WAN یا اینترنت HTTPS انتخاب امن‌تری است چون TFTP رمزنگاری و Authentication مناسب ندارد.

آیا Firmware را می‌توان برای همه Modelها از یک URL داد؟

بهتر است خیر. Artifact باید بر اساس Vendor، Model و در صورت نیاز Hardware Variant تفکیک شود و Rollout نیز مرحله‌ای باشد.