رفع مشکل BLF در تلفن یالینک؛ چرا چراغ داخلی‌ها روشن نمی‌شود؟

در این آموزش از خود Yealink شروع می‌کنیم و مرحله‌به‌مرحله بررسی می‌کنیم که آیا تلفن SUBSCRIBE را ارسال کرده، PBX آن را پذیرفته، NOTIFY برگشته، Event درست انتخاب شده، داخلی موردنظر به Extension یا Hint صحیح نگاشت شده و Subscription قبل از Expire شدن تمدید می‌شود یا نه. در ادامه BLF List، Event List، Permission، dialog-info، Packet Capture و سناریوهای رایج Asterisk را هم بررسی می‌کنیم.

هدف این است که وقتی BLF یالینک کار نمی‌کند فقط کلید را دوباره نسازید؛ بلکه مشخص کنید خرابی دقیقاً در تلفن، شبکه، SIP Subscription، PBX یا Mapping داخلی قرار دارد.

BLF در Yealink چیست؟

BLF یا Busy Lamp Field قابلیتی است که به یک تلفن اجازه می‌دهد وضعیت داخلی یا کاربر دیگری را مانیتور کند.

برای مثال منشی می‌تواند داخلی 201 را روی یکی از کلیدهای Yealink قرار دهد. تلفن بر اساس اطلاعاتی که PBX ارسال می‌کند نشان می‌دهد داخلی 201 آزاد، در حال زنگ‌خوردن یا مشغول تماس است.

بسته به مدل Yealink و تنظیم LED، وضعیت می‌تواند با رنگ یا حالت چشمک‌زدن متفاوت نمایش داده شود. بنابراین رنگ دقیق چراغ را برای تمام مدل‌ها یکسان فرض نکنید؛ چیزی که اهمیت بیشتری دارد State واقعی داخل NOTIFY است.

BLF چگونه پشت صحنه کار می‌کند؟

وقتی BLF برای یک داخلی ساخته می‌شود، تلفن به PBX اعلام می‌کند که می‌خواهد وضعیت آن داخلی را دنبال کند.

فرآیند معمول به این شکل است:

طبق RFC 6665، Subscription دائمی نیست و باید قبل از پایان اعتبار Refresh شود. بنابراین BLF ممکن است در ابتدا کار کند ولی بعد از مدتی به دلیل تمدید نشدن Subscription از کار بیفتد.

Event مورد استفاده BLF چیست؟

Yealink برای BLF معمولی امکان استفاده از Eventهای مختلف را فراهم می‌کند و در مستندات فعلی، Event پیش‌فرض BLF برابر dialog است.

پارامتر مربوط:

account.X.blf.subscribe_event

اگر تلفن SUBSCRIBE را با Event برابر dialog ارسال کند ولی PBX فقط presence را برای آن Resource پشتیبانی کند، Subscription ممکن است Reject شود یا اطلاعات مورد انتظار برگشت داده نشود.

dialog-info چه نقشی در BLF دارد؟

RFC 4235 قالبی برای ارسال وضعیت Dialog تعریف می‌کند. در BLFهای مبتنی بر Dialog Event، PBX معمولاً NOTIFY را با محتوای XML از نوع application/dialog-info+xml ارسال می‌کند.

یک نمونه ساده شبیه این است:

<dialog-info
  xmlns="urn:ietf:params:xml:ns:dialog-info"
  version="1"
  state="full"
  entity="sip:201@pbx.example.local">

  <dialog id="1001">
    <state>confirmed</state>
  </dialog>

</dialog-info>

در این مثال PBX اعلام می‌کند داخلی 201 یک Dialog در وضعیت confirmed دارد.

Stateهای مهم BLF در Yealink

Yealink در راهنمای عیب‌یابی فعلی خود چهار State رایج را برای NOTIFY ذکر می‌کند.

اگر چراغ اشتباه است، اول XML داخل NOTIFY را ببینید. اگر PBX خودش State اشتباه می‌فرستد، تغییر تنظیم LED تلفن مشکل اصلی را حل نمی‌کند.

مرحله اول: مطمئن شوید BLF Key درست ساخته شده است

برای یک BLF ساده باید Account و شماره داخلی مانیتورشونده درست انتخاب شده باشند.

نمونه Auto Provisioning در Yealink:

linekey.1.type = 16
linekey.1.line = 1
linekey.1.value = 201
linekey.1.label = داخلی 201

در این مثال تلفن با Account شماره 1 وضعیت Resource مربوط به 201 را مانیتور می‌کند.

اگر Value اشتباه، Extension قدیمی یا Account اشتباه انتخاب شده باشد، ممکن است PBX Subscription را به Resource موردنظر شما نگاشت نکند.

Extension Mapping را دقیق بررسی کنید

یکی از رایج‌ترین خطاها این است که شماره‌ای که روی BLF Key نوشته‌اید با Resource واقعی PBX یکی نیست.

برای مثال ممکن است کاربر با داخلی 201 تماس بگیرد، اما Hint یا Subscription Resource در PBX با نام دیگری ساخته شده باشد.

در چنین حالتی تماس به 201 می‌تواند کاملاً سالم باشد ولی BLF به دلیل Mapping اشتباه کار نکند.

مرحله دوم: Packet Capture بگیرید

برای BLF، حدس‌زدن بسیار کمتر از دیدن SIP Trace ارزش دارد.

از Diagnostic تلفن Yealink یک Packet Capture بگیرید، تلفن را Reboot کنید یا BLF Key را دوباره Provision کنید و سپس فایل را در Wireshark باز کنید.

برای دیدن SIP:

sip

یا برای محدودکردن نمایش به پیام‌های BLF:

sip.Method == "SUBSCRIBE" || sip.Method == "NOTIFY"

اول ببینید Yealink اصلاً SUBSCRIBE می‌فرستد یا نه

اگر هیچ SUBSCRIBE از تلفن خارج نمی‌شود، هنوز PBX را مقصر ندانید.

موارد زیر را بررسی کنید:

BLF Key واقعاً Type = BLF است.

Account انتخاب‌شده Registered است.

Value داخلی خالی یا اشتباه نیست.

Provisioning تنظیم Key را بازنویسی نکرده است.

Firmware آن مدل از BLF پشتیبانی می‌کند.

Yealink در مستندات خود نیز عیب‌یابی را از همین نقطه شروع می‌کند: اول وجود SUBSCRIBE بررسی می‌شود، سپس پاسخ Server.

SUBSCRIBE سالم چه چیزی باید داشته باشد؟

در SIP Trace مواردی مثل Request-URI، Event و Expires اهمیت دارند.

نمونه مفهومی:

SUBSCRIBE sip:201@pbx.example.local SIP/2.0
Event: dialog
Expires: 1800
Accept: application/dialog-info+xml

این مثال نشان می‌دهد تلفن می‌خواهد Resource شماره 201 را با Event برابر dialog مانیتور کند.

مرحله سوم: پاسخ PBX به SUBSCRIBE را بررسی کنید

بعد از SUBSCRIBE باید پاسخ Server را ببینید.

وجود 401 به‌تنهایی خطا نیست. در بعضی سیستم‌ها اولین SUBSCRIBE Challenge می‌شود و تلفن سپس SUBSCRIBE دیگری با Authentication می‌فرستد.

اگر SUBSCRIBE ارسال می‌شود ولی هیچ پاسخ نمی‌آید

در این حالت Network Path را بررسی کنید.

Firewall یا SBC ممکن است REGISTER و INVITE را عبور دهد ولی SUBSCRIBE را Drop کند.

این مسئله توضیح می‌دهد چرا تماس‌ها کاملاً سالم‌اند ولی BLF کار نمی‌کند.

اگر Yealink از اینترنتی کار می‌کند ولی روی شبکه دیگر مشکل دارد، بررسی NAT و Firewall نیز اهمیت پیدا می‌کند. راهنمای عیب‌یابی Yealink روی اینترنت‌های مختلف برای این بخش مرتبط است.

مرحله چهارم: آیا NOTIFY از PBX برمی‌گردد؟

پذیرفته‌شدن SUBSCRIBE پایان کار نیست.

PBX باید NOTIFY وضعیت فعلی را به تلفن بفرستد و با هر تغییر State نیز Notification جدید ارسال کند.

Yealink در راهنمای رسمی BLF توصیه می‌کند بعد از مشاهده SUBSCRIBE مستقیماً بررسی کنید آیا Server NOTIFY ارسال کرده است یا خیر.

اگر NOTIFY وجود ندارد ولی SUBSCRIBE با موفقیت پذیرفته شده، مشکل بیشتر به PBX، Hint، Permission یا Server-side BLF نزدیک می‌شود.

اگر NOTIFY می‌آید ولی چراغ BLF تغییر نمی‌کند

این حالت بسیار مهم است؛ چون نشان می‌دهد Network و Subscription تا حد زیادی کار می‌کنند.

حالا XML داخل NOTIFY را باز کنید و این موارد را بررسی کنید:

Resource درست است.

State درست است.

Version درست جلو می‌رود.

Content-Type با فرمت قابل فهم تلفن سازگار است.

Subscription-State فعال است.

مشکل معروف dialog-info Version در Yealink

Yealink یک سناریوی رسمی برای حالتی دارد که BLF State با وضعیت واقعی Extension هماهنگ نیست.

فرض کنید NOTIFY قبلی چنین Versionی داشته است:

version="3"

اما Notification بعدی به‌جای Version 4 چنین باشد:

version="2"

Yealink توضیح می‌دهد در Firmwareهای V83 و جدیدتر، تلفن می‌تواند Version عقب‌تر را نادیده بگیرد. نتیجه این است که PBX NOTIFY ارسال کرده ولی LED همچنان State قبلی را نشان می‌دهد.

پارامتر Compatibility مربوط به Dialog Version

Yealink برای چنین محیط‌هایی امکان غیرفعال‌کردن Dialog Version Verification را مستند کرده است:

sip.dialog_version_check.enable = 0

این تنظیم را راه‌حل عمومی تمام مشکلات BLF در نظر نگیرید. ابتدا PCAP را بررسی کنید و مطمئن شوید واقعاً PBX Version نامرتب ارسال می‌کند. در حالت ایده‌آل علت Sequence اشتباه در Server نیز باید اصلاح شود.

مرحله پنجم: Expiry و تمدید Subscription را بررسی کنید

Subscription دائمی نیست.

Yealink پارامتر زیر را برای مدت Subscription مستند کرده است:

account.X.blf.subscribe_period

در مستندات فعلی بسیاری از تلفن‌های Yealink مقدار پیش‌فرض ۱۸۰۰ ثانیه یعنی ۳۰ دقیقه است.

اگر BLF دقیقاً بعد از حدود ۳۰ دقیقه یا در بازه‌ای ثابت از کار می‌افتد، Refresh شدن Subscription را در PCAP بررسی کنید.

نشانه مشکل Subscription Refresh

سناریوی典型:

در این حالت Reboot فقط Subscription را دوباره می‌سازد و علت واقعی را درمان نمی‌کند.

Subscription-State داخل NOTIFY را بررسی کنید

RFC 6665 الزام می‌کند NOTIFY دارای Header مربوط به Subscription State باشد.

برای مثال:

Subscription-State: active;expires=1800

اگر Server Subscription را با State برابر terminated تمام می‌کند، Yealink ممکن است مجبور به Subscribe مجدد شود.

Yealink بعد از NOTIFY با State=terminated چه می‌کند؟

Yealink پارامتری برای تعیین فاصله Re-subscribe بعد از دریافت NOTIFY Terminated دارد:

sip.terminate_notify_sub_delay_time

در مستند فعلی مقدار 0 به معنی Re-subscribe فوری است.

اگر PBX دائماً Subscription را Terminate می‌کند، فقط زمان Re-subscribe را تغییر ندهید؛ علت Termination را روی Server بررسی کنید.

مرحله ششم: Permission سمت PBX را بررسی کنید

BLF در بسیاری از PBXها باید روی Server اجازه داده شود.

ممکن است User بتواند تماس بگیرد ولی اجازه Subscribe کردن به وضعیت داخلی دیگر را نداشته باشد.

این موضوع مخصوصاً در سیستم‌های Multi-tenant، Hosted PBX و Provider-managed مهم است.

اگر SUBSCRIBE با 403 رد می‌شود، Permissions و BLF Policy را بررسی کنید.

BLF Pickup با خود BLF یکی نیست

ممکن است چراغ وضعیت کاملاً درست کار کند اما وقتی داخلی زنگ می‌خورد با فشار BLF نتوانید تماس را Pickup کنید.

در این حالت Subscription سالم است و مشکل بیشتر به Directed Call Pickup مربوط می‌شود.

Yealink نیز تأکید می‌کند قابلیت BLF Pickup به پشتیبانی Server و Feature Code صحیح وابسته است.

Pickup Code را جداگانه بررسی کنید

بسته به PBX ممکن است Directed Pickup Code چیزی شبیه `*8`، `**` یا کد اختصاصی دیگری باشد.

آن را از مستندات PBX بگیرید و فرض نکنید همه سیستم‌ها یک کد دارند.

در Yealink پارامترهای BLF Pickup و BLF List Pickup می‌توانند جداگانه تنظیم شوند.

مرحله هفتم: BLF List با BLF معمولی فرق دارد

در BLF معمولی تلفن برای یک Resource خاص Subscribe می‌کند.

در BLF List تلفن به یک List URI روی Server Subscribe می‌کند و PBX وضعیت چند داخلی را داخل Notificationهای Resource List برمی‌گرداند.

Yealink پارامتر زیر را برای BLF List URI مستند کرده است:

account.1.blf.blf_list_uri = blf-list@pbx.example.local

اما ساخت خود List باید سمت PBX انجام شود.

اگر BLF List خالی است

Yealink در نسخه‌های جدیدتر خانواده‌های مختلف T3X، T4X و T5X منطق نمایش BLF List را تغییر داده است: اگر Server هیچ محتوایی برای BLF List Push نکند، Key می‌تواند خالی نمایش داده شود.

پس خالی‌بودن کلید همیشه به معنی خراب‌شدن LCD یا Provisioning نیست؛ ممکن است Server برای آن Resource محتوایی ارسال نکرده باشد.

Event List و Resource List را روی PBX بررسی کنید

اگر از BLF List استفاده می‌کنید، PBX باید Resource List را بشناسد و اعضای List واقعاً وجود داشته باشند.

اگر List شامل داخلی 201، 202 و 203 است ولی 203 روی PBX حذف شده، رفتار آن Resource ممکن است با بقیه متفاوت باشد.

همچنین PBX باید قالب List Notification مورد انتظار Client را پشتیبانی کند.

مرحله هشتم: Out-of-dialog NOTIFY را بررسی کنید

در بعضی محیط‌ها Server ممکن است NOTIFYی ارسال کند که خارج از BLF Dialog معمول تلفن است.

Yealink برای کنترل این رفتار پارامتر زیر را دارد:

account.X.out_dialog_blf_enable

مقدار پیش‌فرض در مستندات فعلی Yealink غیرفعال است.

این گزینه را بدون Trace فعال نکنید؛ ابتدا مشخص کنید Server واقعاً NOTIFY خارج از Subscription Dialog می‌فرستد.

Host Matching در NOTIFY چه نقشی دارد؟

Yealink امکان محدودکردن پذیرش NOTIFY بر اساس Host را هم دارد:

account.X.blf.match_host.enable

اگر این قابلیت فعال باشد، تلفن فقط NOTIFYهایی را می‌پذیرد که Host آن‌ها با Host مورد انتظار Subscription هماهنگ باشد.

در محیط دارای SBC، Proxy یا Domain Rewrite، این گزینه می‌تواند در عیب‌یابی اهمیت پیدا کند.

مرحله نهم: Asterisk را چگونه برای BLF بررسی کنیم؟

اگر PBX شما Asterisk است، BLF معمولاً به Extension State و Hintها وابسته است.

اول Hintها را ببینید:

core show hints

اگر داخلی مانیتورشونده Hint ندارد یا Hint به Device اشتباه اشاره می‌کند، Asterisk State مورد انتظار را تولید نمی‌کند.

نمونه Hint در Asterisk

در یک Dialplan ساده:

exten => 201,hint,PJSIP/201

در محیط واقعی Context، Endpoint Name و ساختار Dialplan را با PBX خودتان تطبیق دهید.

اگر Hint وجود دارد ولی Subscription رد می‌شود

در Asterisk PJSIP بررسی کنید ماژول‌های Subscription فعال باشند.

module show like res_pjsip_pubsub
module show like res_pjsip_exten_state

Asterisk مستند کرده است که `res_pjsip_pubsub.so` هسته مدیریت Subscriptionهاست و برای Presence/Dialog Info نیز `res_pjsip_exten_state.so` باید در دسترس باشد.

برای دیدن SUBSCRIBE و NOTIFY در Asterisk

pjsip set logger on

مشکل را بازتولید کنید و سپس SUBSCRIBE، Response و NOTIFY را بررسی کنید.

پس از پایان عیب‌یابی Logging اضافی را خاموش کنید تا حجم Log بی‌دلیل بالا نرود.

Context اشتباه در Asterisk می‌تواند BLF را خراب کند

Asterisk در راهنمای PJSIP توضیح می‌دهد اگر Extension مورد Subscribe در Context مرتبط وجود نداشته باشد یا Hint نداشته باشد، Subscription نمی‌تواند State موردنظر را پیدا کند.

بنابراین فقط وجود داخلی 201 کافی نیست؛ Hint باید در Context درست برای Endpoint Subscriber قابل Resolve باشد.

مرحله دهم: چند Device برای یک داخلی را در نظر بگیرید

گاهی داخلی 201 روی تلفن رومیزی و Softphone هم‌زمان Register شده است.

PBX ممکن است State چند Device را Aggregate کند.

در این حالت تعریف Business Logic اهمیت دارد: اگر یکی از Deviceها Busy و دیگری Idle باشد، PBX چه Stateی برای Extension گزارش می‌کند؟

این رفتار سمت PBX است و Yealink فقط State دریافتی را نمایش می‌دهد.

چرا BLF گاهی Busy می‌ماند؟

چند علت رایج وجود دارد:

PBX هنوز Device State را Busy می‌داند.

NOTIFY پایان تماس ارسال نشده است.

NOTIFY ارسال شده ولی در شبکه Drop شده است.

dialog-info Version عقب رفته و Yealink آن را Ignore کرده است.

Extension به چند Device نگاشت شده و یکی هنوز Busy است.

Subscription منقضی یا Terminate شده است.

چرا BLF خاموش است؟

خاموش بودن LED در همه مدل‌ها دقیقاً یک معنی ندارد، اما در مستندات Yealink یکی از حالت‌های Off می‌تواند زمانی باشد که خط مانیتورشونده Register نیست یا اصلاً وجود ندارد.

اگر BLF همیشه خاموش است، قبل از تغییر LED Pattern بررسی کنید:

Resource درست است.

SUBSCRIBE ارسال شده است.

PBX جواب داده است.

NOTIFY رسیده است.

داخلی موردنظر روی PBX وجود دارد.

چرا BLF با تأخیر تغییر می‌کند؟

اگر وضعیت نهایتاً درست می‌شود ولی چند ثانیه یا بیشتر تأخیر دارد، Timestamp پیام‌ها را در Capture مقایسه کنید.

سه زمان مهم وجود دارد:

اگر PBX خود NOTIFY را دیر می‌فرستد، مشکل از تلفن نیست. اگر NOTIFY فوری رسیده ولی LED دیر تغییر کرده، Firmware و Processing تلفن بررسی شود.

NAT و Firewall چگونه BLF را خراب می‌کنند؟

BLF برخلاف تماس معمولی به Subscription طولانی‌مدت و NOTIFYهای دوره‌ای وابسته است.

در شبکه‌های NATشده ممکن است REGISTER و حتی تماس کار کند، اما مسیر برگشت NOTIFY پس از مدتی خراب شود.

اگر BLF روی LAN سالم ولی روی تلفن Remote ناپایدار است، NAT Binding، SIP ALG، Firewall State و Contact/Route را بررسی کنید.

این موضوع با مشکلات رجیستر دوره‌ای هم‌پوشانی دارد؛ راهنمای قطع و وصل شدن رجیستر Yealink در طول روز برای بررسی NAT و Timeout مفید است.

Firewall باید SUBSCRIBE و NOTIFY را هم عبور دهد

فقط Allow کردن INVITE کافی نیست.

اگر Firewall یا SIP-aware Gateway روش‌های SIP را Filter می‌کند، بررسی کنید SUBSCRIBE و NOTIFY نیز مطابق Policy مجاز باشند.

در SBCهای سازمانی نیز ممکن است Event Packageها یا Subscriptionها Policy جداگانه داشته باشند.

مرحله یازدهم: Auto Provisioning را بررسی کنید

گاهی BLF را از Web UI درست می‌کنید اما بعد از Reboot دوباره خراب می‌شود.

در این حالت MAC CFG، Common CFG یا PBX Device Template می‌تواند DSS Key را بازنویسی کند.

مثلاً شما Value را از 202 به 201 تغییر می‌دهید، ولی Provisioning دوباره 202 را Push می‌کند.

اگر تنظیمات BLF بعد از Reboot برمی‌گردد، راهنمای عیب‌یابی Auto Provisioning یالینک نیز مرتبط است.

Firmware را قبل از تغییر بررسی کنید

رفتار BLF بین Firmwareهای مختلف می‌تواند تفاوت داشته باشد؛ نمونه روشن آن Dialog Version Verification در V83 و جدیدتر است.

قبل از Update یا Downgrade:

مدل دقیق را ثبت کنید.

Firmware فعلی را ثبت کنید.

Release Notes را بررسی کنید.

از Configuration Backup بگیرید.

مشکل را با PCAP اثبات کنید.

Update Firmware بدون فهمیدن علت BLF ممکن است فقط متغیر جدیدی وارد عیب‌یابی کند.

یک تست تمیز برای BLF بسازید

اگر ده‌ها BLF دارید، عیب‌یابی را روی همه آن‌ها هم‌زمان انجام ندهید.

یک تلفن Subscriber و یک Extension مانیتورشونده انتخاب کنید.

سپس این سه حالت را ایجاد کنید: 201 آزاد، 201 در حال زنگ‌خوردن و 201 در تماس. برای هر حالت NOTIFY را با LED مقایسه کنید.

مسیر سریع تشخیص BLF خراب

چک‌لیست کامل BLF Yealink

پرسش‌های متداول درباره BLF در Yealink

چرا BLF Yealink اصلاً روشن نمی‌شود؟

ابتدا بررسی کنید تلفن SUBSCRIBE ارسال می‌کند یا خیر. اگر SUBSCRIBE وجود ندارد، تنظیم BLF Key، Account و Provisioning را بررسی کنید. اگر SUBSCRIBE ارسال شده ولی NOTIFY دریافت نمی‌شود، PBX، Permission و Network باید بررسی شوند.

چرا BLF داخلی Busy می‌ماند در حالی که تماس تمام شده است؟

ممکن است PBX State پایان تماس را ارسال نکرده باشد، NOTIFY در شبکه از بین رفته باشد یا dialog-info Version جدید کمتر از Version قبلی باشد و Yealink آن را نادیده بگیرد.

SUBSCRIBE و NOTIFY چه ارتباطی با BLF دارند؟

Yealink برای مانیتورکردن داخلی SUBSCRIBE می‌فرستد و PBX وضعیت داخلی را با NOTIFY اعلام می‌کند. بدون Subscription و Notification صحیح، تلفن اطلاعات قابل اتکایی برای تغییر BLF ندارد.

dialog و presence چه تفاوتی دارند؟

dialog وضعیت Sessionها و تماس‌های SIP را توصیف می‌کند و برای BLF بسیار رایج است. presence مفهوم حضور کاربر را پوشش می‌دهد. Yealink اجازه انتخاب Event را می‌دهد و PBX باید Event انتخاب‌شده را پشتیبانی کند.

چرا BLF هر ۳۰ دقیقه از کار می‌افتد؟

در بسیاری از Yealinkها BLF Subscription Period به‌صورت پیش‌فرض ۱۸۰۰ ثانیه است. اگر Refresh Subscription یا مسیر NAT مشکل داشته باشد، BLF می‌تواند بعد از حدود ۳۰ دقیقه از کار بیفتد و با Reboot دوباره موقتاً سالم شود.

BLF List چیست؟

به‌جای Subscribe جداگانه برای هر داخلی، تلفن به یک BLF List URI روی Server Subscribe می‌کند و PBX وضعیت مجموعه‌ای از Resourceها را داخل Notification List ارسال می‌کند. خود List باید روی PBX پشتیبانی و تعریف شده باشد.

چرا BLF کار می‌کند ولی Pickup کار نمی‌کند؟

BLF State و Directed Call Pickup دو قابلیت مرتبط اما جدا هستند. برای Pickup باید PBX آن را پشتیبانی کند و Feature Code صحیح روی Yealink تعریف شده باشد.

چرا BLF روی یک تلفن درست و روی تلفن دیگر اشتباه است؟

Firmware، Account، Event، DSS Key، Subscription Period و Provisioning دو دستگاه را مقایسه کنید. PCAP هر دو تلفن نیز نشان می‌دهد آیا NOTIFYهای یکسان دریافت می‌کنند یا خیر.

آیا Factory Reset برای مشکل BLF لازم است؟

معمولاً خیر. BLF بیشتر به Subscription، PBX State، Mapping، Permission و Provisioning مربوط است. Factory Reset بدون PCAP معمولاً اطلاعات مفید عیب‌یابی را از بین می‌برد.

جمع‌بندی

وقتی BLF یالینک کار نمی‌کند، رنگ LED آخرین چیزی است که باید بررسی شود. اول باید مطمئن شوید تلفن SUBSCRIBE را برای Resource صحیح ارسال می‌کند، PBX Subscription را می‌پذیرد و NOTIFYهای حاوی State واقعی به Yealink برمی‌گردند.

اگر NOTIFY وجود دارد ولی وضعیت LED اشتباه است، XML مربوط به dialog-info، State و به‌خصوص Version را بررسی کنید. Yealink در Firmwareهای V83 و جدیدتر می‌تواند Notificationهایی با Version عقب‌تر را Ignore کند؛ بنابراین State قدیمی روی تلفن باقی می‌ماند.

اگر BLF بعد از مدت مشخصی خراب می‌شود، Subscription Period و Refresh را بررسی کنید. در BLF List نیز List URI و Resource List سمت PBX اهمیت دارند. در Asterisk، Hint، Context و ماژول‌های PJSIP Subscription باید درست باشند.

با کنار هم گذاشتن PCAP تلفن، SIP Log سرور و State واقعی Extension معمولاً می‌توان مشخص کرد مشکل از Yealink است یا PBX؛ بدون اینکه به Factory Reset یا تغییر تصادفی Firmware نیاز داشته باشید.