چرا کنفرانس در تلفن یالینک کار نمی‌کند؟ رفع مشکل تماس سه‌نفره

در Local Conference خود تلفن Yealink نقش میزبان را دارد و صدای دو تماس را با هم ترکیب می‌کند. در Network Conference تلفن فقط درخواست ایجاد یا گسترش کنفرانس را به PBX می‌فرستد و Bridge اصلی روی سانترال یا Conference Server ساخته می‌شود.

در این آموزش ابتدا نوع Conference را مشخص می‌کنیم، سپس Call Leg دوم، SIP Signaling، Conference URI، REFER، SDP و Codecها را بررسی می‌کنیم. در ادامه نیز محدودیت تعداد اعضا، تنظیمات Asterisk ConfBridge، مشکل صدا بعد از Merge و رفتار Firmware را بررسی می‌کنیم تا مشخص شود ایراد از Yealink است یا مرکز تلفن.

Local Conference و Network Conference چه تفاوتی دارند؟

اول مشخص کنید Yealink روی Local است یا Network Conference

Yealink پارامتر زیر را برای انتخاب نوع Conference مستند کرده است:

account.X.conf_type

طبق مستندات فعلی Yealink مقدار پیش‌فرض Local Conference است.

در Web UI بسیاری از مدل‌های فعلی مسیر مشابه زیر وجود دارد:

Account → Advanced → Conference Type

اگر تلفن روی Network Conference قرار گرفته ولی سانترال شما Conference URI و Conference Focus مناسب ندارد، دکمه Conference ممکن است رفتاری متفاوت از انتظار داشته باشد یا فرآیند اضافه‌کردن نفر سوم شکست بخورد.

Local Conference در Yealink چگونه ساخته می‌شود؟

در یک کنفرانس سه‌نفره محلی معمولاً این اتفاق‌ها رخ می‌دهد:

در راهنمای فعلی Yealink نیز همین روند برای Local Conference توضیح داده شده است: تماس اول برقرار می‌شود، Conference یک تماس جدید ایجاد می‌کند و بعد از پاسخ نفر دوم، Conference یا Merge دوباره انتخاب می‌شود.

اگر تماس دوم اصلاً برقرار نمی‌شود، Conference هنوز مقصر نیست

یکی از مهم‌ترین تست‌ها این است که قبل از Merge ببینید آیا Call Leg دوم واقعاً سالم ساخته می‌شود یا خیر.

فرض کنید با داخلی 201 در تماس هستید و می‌خواهید 202 را وارد Conference کنید.

اگر بعد از زدن Conference، تماس 201 روی Hold می‌رود اما تماس با 202 اصلاً برقرار نمی‌شود، هنوز وارد مرحله Mixing نشده‌اید.

در این حالت موارد زیر مطرح‌اند:

PBX اجازه تماس هم‌زمان دوم به همان Account را نمی‌دهد.

Route داخلی 202 مشکل دارد.

Codec مشترکی برای تماس دوم وجود ندارد.

سانترال یا Provider محدودیت Concurrent Call اعمال کرده است.

Firewall یا NAT تماس دوم را مختل کرده است.

یک تست ساده برای جداکردن مشکل Conference از تماس عادی

قبل از ساخت Conference، از همان تلفن مستقیماً با داخلی دوم تماس بگیرید.

محدودیت تماس هم‌زمان روی PBX را بررسی کنید

Local Conference داخل تلفن ساخته می‌شود، اما سانترال همچنان دو SIP Dialog جداگانه برای همان Yealink می‌بیند.

بنابراین اگر PBX یا Provider برای داخلی فقط یک تماس هم‌زمان مجاز کرده باشد، ممکن است تماس اول سالم باشد اما هنگام ساخت Call Leg دوم پاسخ Busy یا Forbidden دریافت کنید.

این محدودیت می‌تواند در قسمت‌هایی مانند Endpoint Policy، Extension Limit، Concurrent Calls، Channel Limit یا Class of Service تعریف شده باشد.

Packet Capture بهترین راه تشخیص است

اگر مشخص نیست تماس دوم کجا خراب می‌شود، PCAP تلفن را قبل از شروع تماس فعال کنید و کل سناریو را تا لحظه شکست Conference ضبط کنید.

در Wireshark ابتدا SIP را نمایش دهید:

sip

برای دیدن INVITEها:

sip.Method == "INVITE"

و برای بررسی هم‌زمان Media و SIP:

sip || rtp

در Local Conference انتظار چه SIP Signalingی داشته باشیم؟

در Local Conference معمولاً تلفن دو تماس جدا دارد.

یک SIP Dialog بین Yealink و نفر اول.

و یک SIP Dialog دیگر بین Yealink و نفر دوم.

خود Merge Audio داخل Phone انجام می‌شود. بنابراین نباید صرفاً به دنبال REFER یا Conference URI باشید.

اگر هر دو Dialog کاملاً سالم‌اند اما با زدن Merge کنفرانس تشکیل نمی‌شود، مشکل به Firmware، Conference Type یا رفتار Local Conference نزدیک‌تر می‌شود.

تماس اول بعد از زدن Conference باید Hold شود

وقتی Conference را برای تماس نفر دوم انتخاب می‌کنید، تماس اول معمولاً Hold می‌شود.

در SIP ممکن است SDP جدید با مشخصه Hold ارسال شود.

بسته به Implementation می‌توانید تغییراتی مانند:

a=sendonly

یا سایر مدل‌های استاندارد Hold را در SDP ببینید.

اگر PBX با Re-INVITE مربوط به Hold مشکل دارد، ممکن است حتی قبل از اضافه‌کردن نفر سوم رفتار غیرعادی دیده شود.

اگر نفر دوم Answer می‌کند ولی Merge انجام نمی‌شود

این حالت بسیار مهم است، چون ثابت می‌کند Routing و Call Setup هر دو تماس تا حد زیادی سالم هستند.

حالا این موارد را بررسی کنید:

Conference Type واقعاً Local باشد.

Firmware دستگاه را ثبت کنید.

دکمه Conference یا Merge مطابق مدل درست استفاده شود.

هر دو تماس روی Account یا Line قابل پشتیبانی باشند.

PCAP و Syslog Yealink را در لحظه Merge بررسی کنید.

Local Conference چند نفر را پشتیبانی می‌کند؟

در مستندات فعلی Yealink برای بسیاری از SIP Phoneها، Local Conference تا سه طرف شامل خود شما پشتیبانی می‌شود.

یعنی:

بعضی محصولات Conference Phone مانند CP930W و CP935W ظرفیت Local بیشتری دارند، بنابراین عدد را برای همه مدل‌ها یکسان فرض نکنید.

اگر میزبان Local Conference تماس را قطع کند چه می‌شود؟

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

چون خود Yealink میزبان Local Conference است، خروج Initiator می‌تواند باعث قطع Conference شود.

Yealink پارامتر زیر را برای رفتار بعد از خروج میزبان مستند کرده است:

transfer.tran_others_after_conf_enable = 1

در مدل‌های پشتیبانی‌شده، فعال‌کردن این گزینه اجازه می‌دهد بعد از خروج Initiator دو طرف دیگر به هم منتقل شوند و ارتباطشان ادامه پیدا کند.

این پارامتر فقط برای Local Conference مرتبط است.

Network Conference چه زمانی استفاده می‌شود؟

اگر می‌خواهید بیش از تعداد محدود Local Participant داشته باشید، مدیریت Conference روی Server باشد یا کاربران بدون وابستگی به تلفن میزبان در Bridge باقی بمانند، Network Conference مناسب‌تر است.

Yealink این حالت را Centralized Conference نیز می‌نامد.

در این معماری PBX یا Conference Focus مسئول Bridge است.

فعال‌کردن Network Conference در Yealink

Conference Type باید روی Network قرار بگیرد:

account.1.conf_type = 2

سپس Conference URI باید تعریف شود:

account.1.conf_uri = conference@pbx.example.local

آدرس بالا فقط نمونه است. Conference URI واقعی باید توسط PBX یا Administrator مرکز تلفن شما مشخص شود.

اگر Conference URI خالی یا اشتباه باشد

این یکی از اولین مواردی است که در Network Conference باید بررسی شود.

Yealink می‌تواند روی Network Conference تنظیم شده باشد اما هیچ Conference Resource معتبری در اختیار نداشته باشد.

در این حالت Local Conference ممکن است با تغییر Conference Type کار کند، در حالی که Network Conference شکست می‌خورد.

REFER در Network Conference چه نقشی دارد؟

Yealink در مستندات فعلی خود صراحتاً اعلام می‌کند Network Conference با مکانیزم REFER مطرح‌شده در RFC 4579 پیاده‌سازی می‌شود و به پشتیبانی SIP Server وابسته است.

در یک سناریوی Conference، REFER می‌تواند از Conference Focus بخواهد Participant جدیدی را وارد Bridge کند.

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

REFER sip:conference@pbx.example.local SIP/2.0
Refer-To: <sip:202@pbx.example.local>

اگر PBX یا SBC از این نوع Conference Control پشتیبانی نکند، صرف فعال‌کردن Network Conference در Yealink کافی نیست.

اگر Local Conference کار می‌کند ولی Network Conference نه

این نتیجه تقریباً خود Phone Audio Mixer را از مظنون اصلی خارج می‌کند.

تمرکز را روی این بخش‌ها قرار دهید:

Conference Type.

Conference URI.

REFER.

PBX Conference Feature.

Permission کاربر.

Conference Focus.

SBC یا Firewall.

اگر Network Conference کار می‌کند ولی Local نه

این حالت برعکس است.

PBX Conference Service احتمالاً سالم است و باید رفتار Local Phone را بررسی کنید.

Firmware، Local Conference Type، تماس دوم و Merge Audio روی تلفن مهم‌تر می‌شوند.

Codec Negotiation چگونه Conference را خراب می‌کند؟

در SIP، Codec از طریق SDP و مدل Offer/Answer انتخاب می‌شود.

RFC 3264 می‌گوید Codec قابل استفاده باید از اشتراک Capabilityهای دو طرف انتخاب شود.

برای مثال Yealink ممکن است این Codecها را Offer کند:

m=audio 11780 RTP/AVP 9 0 8
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000

اگر مقصد هیچ‌کدام از Codecهای Offered را قبول نکند، تماس دوم ممکن است اصلاً برقرار نشود.

خطای 488 در Call Leg دوم را جدی بگیرید

اگر هنگام شماره‌گیری نفر سوم پاسخی مانند زیر می‌بینید:

SIP/2.0 488 Not Acceptable Here

SDP Offer و Answer را بررسی کنید.

نبود Codec مشترک، Media Policy، SRTP Requirement یا سایر ناسازگاری‌های SDP می‌توانند 488 ایجاد کنند.

در چنین شرایطی دکمه Conference مشکل اصلی نیست؛ Call Leg دوم قبل از Merge شکست خورده است.

آیا هر سه نفر باید دقیقاً یک Codec داشته باشند؟

در Local Conference لزوماً نباید فرض کرد تمام Call Legها از یک Codec یکسان استفاده می‌کنند. هر تماس SIP SDP خود را دارد و Phone باید Media مربوط به هر Leg را پردازش کند.

اما هر Leg باید Codec سازگار خودش را با Yealink پیدا کند.

در Network Conference نیز هر Participant با Conference Bridge مذاکره Media انجام می‌دهد و PBX ممکن است نیاز به Transcoding یا Resampling داشته باشد.

چرا اختلاف Codec در Network Conference مهم‌تر می‌شود؟

وقتی Conference روی PBX ساخته می‌شود، Bridge ممکن است صدای Participantها را Decode، Mix و دوباره Encode کند.

در Asterisk، مستندات ConfBridge توضیح می‌دهند که اختلاف Sampling Rateها باعث Resampling و مصرف پردازشی بیشتر می‌شود.

بنابراین روی Conferenceهای بزرگ‌تر، انتخاب Codec و Sample Rate می‌تواند روی ظرفیت و کیفیت اثر بگذارد.

اگر کنفرانس تشکیل می‌شود ولی صدا خراب است

اگر هر سه نفر داخل Conference هستند اما یکی صدا ندارد، صدا قطع‌و‌وصل می‌شود یا تأخیر زیادی ایجاد شده است، Conference Signaling احتمالاً تا حد زیادی موفق شده است.

در این مرحله باید RTP را بررسی کنید.

برای هر Participant مسیر RTP جدا وجود دارد و NAT، Firewall، Packet Loss، Jitter و Codec می‌توانند روی کیفیت اثر بگذارند.

فرق «Conference تشکیل نمی‌شود» با «Conference بی‌صداست»

PBX Limit در Network Conference را بررسی کنید

Network Conference محدود به توان Yealink نیست؛ محدودیت اصلی می‌تواند روی PBX قرار داشته باشد.

برای نمونه در Asterisk ConfBridge گزینه max_members می‌تواند تعداد اعضای یک Bridge را محدود کند.

نمونه Configuration:

[office_bridge]
type=bridge
max_members=3
internal_sample_rate=auto
mixing_interval=20

در ConfBridge خود Asterisk مقدار پیش‌فرض max_members محدودیت عددی اعمال نمی‌کند، اما Configuration PBX، GUI یا Provider می‌تواند مقدار مشخصی تعیین کرده باشد.

اگر Conference روی Asterisk است، اعضای Bridge را ببینید

در Asterisk CLI:

confbridge list

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

برای یک Conference مشخص:

confbridge list 7000

عدد 7000 فقط نمونه Conference Name است.

Bridge Profile را هم بررسی کنید

برای دیدن تنظیماتی مانند Max Members، Sample Rate و Mixing Interval:

confbridge show profile bridge default_bridge

نام Profile واقعی سیستم ممکن است متفاوت باشد.

برای دیدن SIP Signaling در Asterisk

اگر از PJSIP استفاده می‌کنید:

pjsip set logger on

سپس Conference را بازتولید کنید و INVITE، REFER، Response Code و SDP را بررسی کنید.

بعد از پایان عیب‌یابی Logging اضافی را خاموش کنید.

اگر عضو سوم وارد ConfBridge نمی‌شود

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

Conference Lock نشده باشد.

max_members به سقف نرسیده باشد.

Dialplan عضو سوم را به همان Conference ID بفرستد.

User Profile اجازه ورود داشته باشد.

PIN یا Authentication اشتباه نباشد.

Codec Negotiation تماس عضو سوم شکست نخورده باشد.

Mixing Interval چه اثری دارد؟

Asterisk برای ConfBridge مقدار Mixing Interval را قابل تنظیم می‌داند.

مقادیر معمول شامل 10، 20، 40 و 80 میلی‌ثانیه هستند و مقدار پیش‌فرض در مستندات فعلی 20 میلی‌ثانیه است.

Interval کمتر می‌تواند تأخیر Mixing را کاهش دهد ولی CPU بیشتری مصرف کند. Interval بزرگ‌تر بار CPU را کم می‌کند ولی Delay بیشتری به Bridge اضافه می‌کند.

برای یک کنفرانس سه‌نفره معمولاً اولین مظنون Mixing Interval نیست؛ این تنظیم بیشتر زمانی اهمیت پیدا می‌کند که Server تعداد Conference یا Participant زیادی دارد.

چرا Network Conference روی سرور شلوغ بدصدا می‌شود؟

اگر CPU یا منابع Media Server تحت فشار باشند، Mixing و Transcoding می‌توانند کیفیت را کاهش دهند.

این وضعیت معمولاً به شکل یکی از این علائم دیده می‌شود:

صدای تکه‌تکه.

Delay زیاد.

رباتیک‌شدن صدا.

مشکل فقط هنگام Conferenceهای بزرگ.

تماس دوطرفه عادی سالم ولی Conference ضعیف.

اگر فقط یک نفر داخل Conference صدا ندارد

مشکل را روی همان Call Leg محدود کنید.

در Wireshark جریان RTP مربوط به همان Participant را بررسی کنید.

اگر SIP سالم است ولی RTP فقط در یک جهت جریان دارد، NAT، Firewall و SDP Address را بررسی کنید.

این وضعیت مشابه عیب‌یابی صدای یک‌طرفه در تماس عادی است؛ فقط در Conference چند Media Leg هم‌زمان وجود دارند.

اگر Conference بعد از چند ثانیه قطع می‌شود

مشکل ممکن است اصلاً Conference-specific نباشد.

ACK، Session Timer، NAT، SIP ALG و RTP Timeout را بررسی کنید.

اگر یکی از Call Legها بعد از حدود ۳۰ ثانیه قطع شود، کل Local Conference نیز ممکن است تحت تأثیر قرار بگیرد.

پس Timestamp قطع هر Dialog را جداگانه بررسی کنید.

اگر نفر سوم خارجی است ولی داخلی‌ها کار می‌کنند

فرض کنید Conference بین سه داخلی سالم است اما وقتی یکی از اعضا از Trunk وارد می‌شود Conference شکست می‌خورد.

در این حالت این بخش‌ها اهمیت بیشتری پیدا می‌کنند:

Codecهای مجاز روی Trunk.

Concurrent Call Limit.

License یا Channel Capacity.

Media Anchoring روی SBC.

Outbound/Inbound Route.

Transcoding.

اگر فقط تماس خارجی دوم وارد Conference نمی‌شود

ممکن است PBX برای Account یا Trunk اجازه دو Channel هم‌زمان نداشته باشد.

تماس عادی خارجی موفق بودن، ثابت نمی‌کند دو تماس هم‌زمان خارجی نیز مجازند.

Dashboard Provider یا Trunk Channel Limit را بررسی کنید.

Conference Button کار نمی‌کند اما Merge کار می‌کند

نام و رفتار Softkeyها بین مدل‌های Yealink متفاوت است.

در بعضی مدل‌ها Conference، در بعضی Merge و در مدل‌هایی مانند T58W گزینه Invite دیده می‌شود.

بنابراین آموزش یک مدل قدیمی را دقیقاً روی مدل جدید اجرا نکنید.

Firmware و User Guide همان مدل را بررسی کنید.

اگر Conference Type بعد از Reboot برمی‌گردد

این نشانه Auto Provisioning است.

ممکن است شما Conference Type را در Web UI روی Local قرار دهید، اما MAC CFG یا Common CFG دوباره Network Conference را Push کند.

نمونه:

account.1.conf_type = 2
account.1.conf_uri = conference@pbx.example.local

اگر تنظیمات بعد از Reboot تغییر می‌کنند، قبل از Factory Reset فایل Provisioning را بررسی کنید.

Firmware چه زمانی واقعاً مظنون است؟

اگر Conference قبلاً با همان PBX و همان Network سالم بوده و بلافاصله بعد از Firmware Update خراب شده، Firmware وارد فهرست مظنون‌ها می‌شود.

اما قبل از Downgrade این موارد را ثبت کنید:

Conference Type قبل و بعد.

Conference URI.

PCAP سالم و خراب.

Codec List.

Release Notes.

مدل و Hardware Revision.

صرفاً به دلیل کارنکردن Conference فوراً Firmware را تعویض نکنید.

Factory Reset معمولاً اولین راه‌حل نیست

اگر PBX نفر سوم را Reject می‌کند، Codec مشترک وجود ندارد یا Conference URI اشتباه است، Factory Reset تلفن هیچ‌کدام را اصلاح نمی‌کند.

Reset همچنین ممکن است SIP Account، VLAN و سایر تنظیمات سالم را پاک کند.

ابتدا Trace جمع کنید و محل شکست را مشخص کنید.

تست پنج‌دقیقه‌ای برای مشخص‌کردن مقصر

چک‌لیست کامل عیب‌یابی Conference Yealink

پرسش‌های متداول درباره کنفرانس Yealink

چرا کنفرانس سه‌نفره Yealink کار نمی‌کند؟

ابتدا بررسی کنید Conference روی Local یا Network تنظیم شده است. در Local Conference باید هر دو تماس جداگانه سالم باشند و تلفن آن‌ها را Merge کند. در Network Conference نیز PBX باید Conference URI، REFER و Conference Service را پشتیبانی کند.

Local Conference در Yealink چیست؟

در Local Conference خود تلفن Yealink میزبان است و صدای Call Legها را داخل دستگاه ترکیب می‌کند. در بسیاری از تلفن‌های رومیزی این حالت سه طرف شامل خود کاربر را پشتیبانی می‌کند.

Network Conference چه تفاوتی با Local Conference دارد؟

در Network Conference پردازش اصلی روی SIP Server یا PBX انجام می‌شود. Yealink برای این حالت Conference URI دارد و پیاده‌سازی آن به پشتیبانی سرور، از جمله مکانیزم‌های تعریف‌شده در RFC 4579، وابسته است.

چرا نفر دوم تماس می‌گیرد ولی وارد Conference نمی‌شود؟

اگر هر دو تماس جداگانه برقرار هستند اما Merge انجام نمی‌شود، Conference Type، Firmware و رفتار Local Conference را بررسی کنید. اگر Network Conference فعال است، Conference URI و PBX نیز باید بررسی شوند.

چرا نفر سوم اصلاً زنگ نمی‌خورد؟

در این حالت Conference هنوز تشکیل نشده است. Routing، Concurrent Call Limit، Codec Negotiation، SIP Response و Policy داخلی را بررسی کنید.

آیا Codec می‌تواند باعث خراب‌شدن Conference شود؟

بله. هر Call Leg باید از طریق SDP Codec سازگار پیدا کند. اگر تماس دوم به دلیل نبود Codec مشترک با 488 یا خطای مشابه رد شود، نفر سوم وارد Conference نمی‌شود.

چرا Local Conference کار می‌کند ولی Network Conference نه؟

این حالت معمولاً نشان می‌دهد Phone Mixer سالم است و باید Conference URI، REFER، Permission و Conference Service روی PBX بررسی شوند.

چرا Conference روی Asterisk نفر سوم را قبول نمی‌کند؟

ConfBridge Profile، max_members، Lock State، Dialplan و Codec تماس عضو جدید را بررسی کنید. دستورهای confbridge list و confbridge show profile bridge برای عیب‌یابی مفید هستند.

اگر میزبان Local Conference تماس را قطع کند، بقیه هم قطع می‌شوند؟

بسته به تنظیم دستگاه ممکن است بله. Yealink پارامتر transfer.tran_others_after_conf_enable را برای انتقال دو طرف باقی‌مانده پس از خروج Initiator در Local Conference ارائه می‌کند.

جمع‌بندی

برای رفع مشکل کنفرانس سه‌نفره Yealink ابتدا مشخص کنید تلفن روی Local Conference است یا Network Conference. این مهم‌ترین مرحله عیب‌یابی است، چون در حالت Local خود تلفن Audio Mixer است اما در حالت Network مسئولیت اصلی روی PBX قرار دارد.

اگر تماس دوم اصلاً برقرار نمی‌شود، Conference را کنار بگذارید و Call Setup، Concurrent Call Limit، Routing و Codec را بررسی کنید. اگر هر دو تماس جداگانه سالم هستند ولی Merge انجام نمی‌شود، Conference Type، Firmware و Local Conference Behavior اهمیت بیشتری پیدا می‌کنند.

در Network Conference، Conference URI و پشتیبانی PBX از Conference Control را بررسی کنید. اگر از Asterisk ConfBridge استفاده می‌کنید، تعداد اعضا، Bridge Profile، max_members، Sample Rate و وضعیت Conference را در CLI ببینید.

در نهایت Signaling را از Media جدا کنید. اگر نفر سوم وارد Conference نمی‌شود، SIP و PBX را بررسی کنید؛ اگر هر سه عضو وارد شده‌اند ولی صدا مشکل دارد، RTP، NAT، Codec و کیفیت شبکه را بررسی کنید. با این روش خیلی سریع می‌توان مشخص کرد مشکل واقعاً از Yealink است یا سانترال.