چرا انتقال تماس در تلفن یالینک انجام نمی‌شود؟ رفع مشکل انتقال مستقیم و با هماهنگی

در این راهنما Blind Transfer، Semi-attended Transfer و Attended Transfer را از هم جدا می‌کنیم و سپس بررسی می‌کنیم Yealink دقیقاً چه SIP Messageهایی تولید می‌کند، PBX چه پاسخی می‌دهد، Replaces چگونه ساخته می‌شود، Feature Code چه زمانی وارد ماجرا می‌شود و چرا ممکن است انتقال با یک داخلی کار کند ولی با داخلی دیگر یا تماس خارجی شکست بخورد.

نکته مهم این است که Transfer Key تلفن با Feature Code مرکز تلفن یک چیز نیست. وقتی Yealink به‌صورت Native انتقال SIP انجام می‌دهد معمولاً REFER ارسال می‌شود؛ اما اگر از کدهایی مانند Blind Transfer یا Attended Transfer خود PBX استفاده کنید، انتقال می‌تواند داخل خود مرکز تلفن و با DTMF مدیریت شود. همین تفاوت یکی از بهترین سرنخ‌ها برای پیدا کردن علت خرابی است.

Blind و Attended Transfer در Yealink چه تفاوتی دارند؟

Yealink در مستندات فعلی خود همین سه حالت را تفکیک می‌کند. بنابراین اگر Blind Transfer سالم است ولی Attended Transfer خراب است، یکی از اولین بخش‌هایی که باید بررسی شود Replaces و Dialog دوم است؛ نه صرفاً Routing داخلی مقصد.

Blind Transfer چگونه کار می‌کند؟

فرض کنید داخلی 200 با مشتری در تماس است و می‌خواهد تماس را بدون مشورت به داخلی 201 منتقل کند.

Yealink معمولاً یک REFER می‌فرستد که مقصد جدید داخل Refer-To قرار گرفته است.

REFER sip:pbx.example.local SIP/2.0
Refer-To: <sip:201@pbx.example.local>
Event: refer

در Blind Transfer معمولی نباید انتظار Replaces مربوط به یک Consultation Dialog را داشته باشیم؛ چون انتقال‌دهنده هنوز تماس جداگانه‌ای با مقصد برقرار نکرده است.

بعد از REFER چه اتفاقی می‌افتد؟

REFER فقط به PBX یا User Agent می‌گوید تماس را به مقصد دیگری ارجاع بده. نتیجه واقعی انتقال از طریق Notificationهای مربوط به REFER قابل گزارش است.

در استاندارد REFER، NOTIFY می‌تواند نتیجه عملیات را با محتوای SIP Fragment اعلام کند.

NOTIFY sip:200@phone.local SIP/2.0
Event: refer
Subscription-State: active
Content-Type: message/sipfrag;version=2.0

SIP/2.0 100 Trying

و بعد از موفقیت:

Content-Type: message/sipfrag;version=2.0

SIP/2.0 200 OK

اگر REFER پذیرفته شود ولی عملیات انتقال در مرحله بعد شکست بخورد، ممکن است خود REFER موفق باشد اما NOTIFY نتیجه ناموفق را گزارش کند. به همین دلیل فقط پاسخ REFER را نبینید؛ جریان NOTIFY را هم بررسی کنید.

آیا باید بعد از REFER دنبال 200 OK باشیم یا 202 Accepted؟

در RFC 3515 اولیه، پاسخ 202 Accepted برای REFER پذیرفته‌شده استفاده می‌شد. اما RFC 7647 این رفتار را به‌روزرسانی کرده و استفاده از 202 را Deprecated کرده است؛ پیاده‌سازی مطابق استاندارد جدید باید 200 OK برگرداند.

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

Attended Transfer چرا پیچیده‌تر است؟

در انتقال مشورتی ابتدا تماس اصلی وجود دارد، سپس Yealink یک تماس دوم با مقصد انتقال ایجاد می‌کند.

مثلاً:

A ابتدا B را Hold می‌کند، با C تماس می‌گیرد و بعد از مشورت Transfer را کامل می‌کند.

برای اینکه سیستم بفهمد کدام Dialog باید با کدام Dialog جایگزین شود، اطلاعات Replaces اهمیت پیدا می‌کند.

Replaces چیست؟

هدر Replaces در RFC 3891 تعریف شده و برای جایگزین‌کردن یک SIP Dialog موجود با Dialog جدید استفاده می‌شود. Attended Transfer یکی از کاربردهای اصلی آن است.

در عمل ممکن است Refer-To چیزی شبیه این باشد:

Refer-To: <sip:201@pbx.example.local?Replaces=abc123%40pbx%3Bto-tag%3Dtag201%3Bfrom-tag%3Dtag200>

Call-ID و Tagها باید به Dialog واقعی Consultation Call اشاره کنند.

اگر Replaces اشتباه ساخته شود، در SBC تغییر کند یا PBX نتواند Dialog مرتبط را پیدا کند، Blind Transfer ممکن است کاملاً سالم باشد ولی Attended Transfer شکست بخورد.

خطای 481 در Attended Transfer چه معنی دارد؟

RFC 3891 مشخص می‌کند اگر Replaces نتواند Dialog مطابق با Call-ID و Tagهای اعلام‌شده پیدا کند، درخواست جایگزینی می‌تواند با 481 Call/Transaction Does Not Exist رد شود.

اگر در Trace انتقال مشورتی 481 می‌بینید، این موارد را مقایسه کنید:

Call-ID تماس Consultation.

From-tag.

To-tag.

Refer-To.

Replaces داخل Refer-To.

وجود SBC یا Proxy که Headerها را بازنویسی می‌کند.

مرحله اول: مشخص کنید کدام نوع Transfer خراب است

قبل از Packet Capture سه تست جدا انجام دهید.

مرحله دوم: بررسی کنید Transfer روی Yealink فعال است

Yealink برای فعال یا غیرفعال کردن Call Transfer پارامتر مشخصی دارد:

features.transfer.allow = 1

اگر این قابلیت غیرفعال شده باشد، کاربر ممکن است Transfer Softkey را نبیند یا رفتار دستگاه مطابق انتظار نباشد.

در بسیاری از مدل‌های فعلی مسیر تنظیمات Web UI در بخش:

Features → Transfer

قرار دارد.

تنظیمات اصلی Transfer در Yealink را بررسی کنید

features.transfer.allow
transfer.semi_attend_tran_enable
account.X.transfer_refer_to_contact_header.enable
features.transfer_keep_session2_after_failed.enable
transfer.blind_tran_on_hook_enable
transfer.on_hook_trans_enable

مقدار و حتی وجود بعضی گزینه‌ها می‌تواند بین مدل و Firmware متفاوت باشد؛ بنابراین تنظیمات را با Administrator Guide همان مدل تطبیق دهید.

transfer.semi_attend_tran_enable چه کاری می‌کند؟

این گزینه رفتار Semi-attended Transfer را کنترل می‌کند.

اگر کاربر مقصد را Dial کند و Ringback را بشنود، رفتار فشار دوباره Transfer می‌تواند بر اساس این تنظیم تغییر کند.

اگر کاربران می‌گویند «قبلاً وقتی داخلی زنگ می‌خورد Transfer کامل می‌شد ولی بعد از تغییر Firmware رفتار فرق کرده»، این گزینه را با Configuration قبلی مقایسه کنید.

Refer-To Contact Header در Attended Transfer چرا مهم است؟

Yealink پارامتر زیر را برای تعیین استفاده از اطلاعات Contact در Refer-To انتقال مشورتی دارد:

account.X.transfer_refer_to_contact_header.enable = 1

Yealink این قابلیت را برای استفاده از اطلاعات Contact دریافت‌شده در مرحله Consultation داخل Refer-To مستند کرده است.

اگر PBX یا SBC انتظار URI متفاوتی داشته باشد، تغییر این رفتار می‌تواند روی Attended Transfer اثر بگذارد.

این گزینه را کورکورانه تغییر ندهید؛ ابتدا REFER سالم و خراب را در PCAP مقایسه کنید.

مرحله سوم: Transfer Mode روی DSS یا BLF Key را بررسی کنید

یکی از رایج‌ترین علت‌های رفتاری این است که کاربر تصور می‌کند فشار BLF Key باید تماس جدید بگیرد، اما Yealink آن را به‌عنوان Blind Transfer تنظیم کرده است؛ یا برعکس.

Yealink پارامتر زیر را برای Transfer Mode via DSS Key دارد:

transfer.dsskey_deal_type = 2

این تنظیم برای Speed Dial، BLF/BLF List و Transfer Key دارای Value اهمیت زیادی دارد.

اگر انتقال با BLF Key رفتار اشتباه دارد

فرض کنید هنگام تماس، BLF داخلی 201 را فشار می‌دهید و انتظار Attended Transfer دارید ولی تماس فوراً منتقل می‌شود.

احتمالاً Transfer Mode via DSS Key روی Blind Transfer قرار دارد.

اگر روی Attended تنظیم شود، Yealink ابتدا به داخلی مانیتورشده تماس می‌گیرد و بعد می‌توانید هنگام Ringback یا پس از Answer انتقال را کامل کنید.

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

برای Transfer ناموفق، PCAP یکی از مهم‌ترین ابزارهاست. Capture را قبل از فشار Transfer شروع کنید تا تماس اصلی و تماس Consultation هر دو داخل فایل باشند.

در Wireshark ابتدا SIP را فیلتر کنید:

sip

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

sip.Method == "REFER"

و برای NOTIFYهای مربوط به Transfer:

sip.Method == "NOTIFY"

اگر هیچ REFER از Yealink خارج نمی‌شود

در این حالت ابتدا تلفن را بررسی کنید، نه PBX را.

Transfer Feature ممکن است غیرفعال باشد، DSS Key Mode اشتباه باشد، Softkey توسط Provisioning تغییر کرده باشد یا کاربر در واقع Feature Code دیگری را اجرا کند.

Auto Provisioning نیز ممکن است تنظیمات Transfer را بعد از هر Reboot دوباره اعمال کند.

اگر REFER ارسال می‌شود ولی PBX آن را رد می‌کند

Response Code را بررسی کنید.

Permission سمت PBX را بررسی کنید

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

در Hosted PBXها و سیستم‌های Multi-tenant این Policy بسیار رایج است.

اگر انتقال داخلی به داخلی کار می‌کند اما تماس ورودی از Trunk منتقل نمی‌شود، Permission و Transfer Policy مربوط به Trunk را نیز بررسی کنید.

مرحله پنجم: اگر Blind کار می‌کند ولی Attended نه، Replaces را بررسی کنید

این الگو بسیار تشخیصی است.

Blind Transfer فقط به مقصد انتقال نیاز دارد، ولی Attended Transfer باید Dialog Consultation را نیز به‌درستی شناسایی کند.

در REFER مشورتی، Query مربوط به Replaces را باز کنید و Call-ID و Tagها را با تماس دوم مقایسه کنید.

اگر Match وجود ندارد، مشکل می‌تواند از Yealink، PBX، SBC یا Rewrite شدن SIP Header باشد.

SBC می‌تواند Attended Transfer را خراب کند

در شبکه‌ای که Session Border Controller بین Phone و PBX قرار دارد، SBC ممکن است Contact، Call-ID یا Dialog Routing را تغییر دهد.

این تغییر به‌خودی‌خود ایراد نیست؛ اما اگر Replaces بعد از Rewrite با Dialog قابل تشخیص در سمت مقصد هماهنگ نباشد، Attended Transfer می‌تواند شکست بخورد.

برای تشخیص واقعی، اگر امکان دارد Trace دو سمت SBC را مقایسه کنید.

Supported: replaces را بررسی کنیم؟

RFC 3891 برای قابلیت Replaces یک Option Tag تعریف می‌کند. در بعضی Traceها ممکن است این قابلیت در Headerهای Supported یا Require دیده شود.

اگر یک Endpoint یا Gateway واقعاً Replaces را پشتیبانی نکند، Attended Transfer می‌تواند مشکل داشته باشد در حالی که Blind Transfer همچنان کار می‌کند.

مرحله ششم: نتیجه Transfer را داخل NOTIFY ببینید

گاهی PBX REFER را با موفقیت قبول می‌کند اما مقصد نهایی پاسخ نمی‌دهد یا Dialplan انتقال را Reject می‌کند.

در این حالت NOTIFY ممکن است نتیجه‌ای مانند خطای مقصد را گزارش کند.

بنابراین در Capture فقط این را نبینید که REFER پاسخ 200 گرفته؛ بدنه `message/sipfrag` را هم بررسی کنید.

اگر مقصد Busy باشد چه؟

در Blind Transfer ممکن است کاربر انتقال‌دهنده دیگر در تماس نباشد و مقصد Busy یا Unavailable شود.

Yealink برای سناریوی شکست Blind Transfer گزینه‌ای برای بازگرداندن تماس قبلی مستند کرده است:

features.resume_after_blind_transfer_failed.enable = 1

Yealink این گزینه را برای Resume کردن تماس قبلی در صورت شکست Blind Transfer معرفی کرده است.

Attended Transfer شکست می‌خورد و تماس اصلی هم از دست می‌رود

برای Semi-attended و Attended Transfer نیز Yealink قابلیت نگه‌داشتن Session اصلی در صورت ردشدن انتقال را دارد:

features.transfer_keep_session2_after_failed.enable = 1

این گزینه مشکل Server را درمان نمی‌کند، اما می‌تواند تجربه کاربر را در Transfer ناموفق بهتر کند.

مرحله هفتم: انتقال با Hang Up را بررسی کنید

در بعضی Yealinkها کاربر می‌تواند به‌جای زدن دوباره Transfer، گوشی را روی Hook بگذارد تا انتقال کامل شود.

دو پارامتر مهم:

transfer.blind_tran_on_hook_enable
transfer.on_hook_trans_enable

اولی به Blind Transfer و دومی به Semi-attended/Attended Transfer مربوط است.

اگر کاربران می‌گویند «وقتی گوشی را می‌گذاریم تماس قطع می‌شود ولی Transfer نمی‌شود»، این تنظیمات را با رفتار مورد انتظار مقایسه کنید.

مرحله هشتم: Feature Code مرکز تلفن را از SIP REFER جدا کنید

در بعضی شبکه‌ها Yealink به‌جای Native Transfer با REFER از Feature Code مرکز تلفن استفاده می‌کند.

مثلاً Asterisk قابلیت Blind و Attended Transfer مبتنی بر DTMF را در `features.conf` دارد.

نمونه رسمی مستندات Asterisk:

[featuremap]
blindxfer = #1
atxfer = *2

این فقط نمونه Configuration است. Feature Code واقعی شبکه خودتان را از `features.conf`، PBX GUI یا مستندات مرکز تلفن بررسی کنید.

چرا Feature Code کار می‌کند ولی دکمه Transfer Yealink نه؟

این نتیجه بسیار مهم است.

Asterisk نیز در مستندات رسمی تأکید می‌کند که Core Feature Code Transfer مستقل از Transfer Native در Channel Driverهایی مثل PJSIP است.

پس اگر `*2` یا کد داخلی PBX کار می‌کند ولی Transfer Softkey یالینک شکست می‌خورد، تمرکز را روی REFER، Replaces و SIP Interoperability بگذارید.

اگر Feature Code هم کار نمی‌کند

در Asterisk فقط تعریف DTMF Code کافی نیست. Channel باید اجازه استفاده از Transfer Feature را هم داشته باشد.

این اجازه می‌تواند توسط گزینه‌های Dial، Queue یا Configurationهای مشابه کنترل شود.

Asterisk همچنین برای Attended Transfer نیاز دارد Channelها Answer شده و داخل Bridge قرار گرفته باشند.

وضعیت Feature Code در Asterisk را بررسی کنید

نمونه مستند Asterisk برای Feature Map:

[featuremap]
blindxfer = #1
atxfer = *2

[general]
atxferabort = *3
atxfercomplete = *4
atxferthreeway = *5
atxferswap = *6

کدهای واقعی را بر اساس سیستم خودتان تنظیم کنید و مراقب تداخل آن‌ها با Dialplan، IVR یا Feature Codeهای دیگر باشید.

مرحله نهم: Caller ID بعد از Transfer را با شکست Transfer اشتباه نگیرید

گاهی انتقال واقعاً انجام می‌شود اما Caller ID مقصد اشتباه نمایش داده می‌شود.

این موضوع بیشتر به Connected Identity، Diversion، P-Asserted-Identity یا سیاست PBX مربوط است و نباید آن را با شکست REFER یکی دانست.

اول مشخص کنید آیا تماس واقعاً به مقصد رسیده است یا خیر.

یک‌طرفه شدن صدا بعد از Attended Transfer

اگر انتقال کامل می‌شود اما یکی از طرفین صدا ندارد، خود Transfer احتمالاً موفق شده و مشکل به Media Path منتقل شده است.

در این سناریو RTP، NAT، SDP، SBC و مسیر Media بعد از Re-INVITE یا Dialog Replacement را بررسی کنید.

مشکل یک‌طرفه شدن صدا را با «REFER رد شده» یکی ندانید.

مرحله دهم: NAT و SIP ALG را بررسی کنید

در شبکه داخلی ساده ممکن است Transfer سالم باشد ولی روی تلفن Remote یا پشت Router خراب شود.

SIP ALG می‌تواند Refer-To، Contact یا سایر Headerهای SIP را تغییر دهد و Attended Transfer را به‌خصوص در سناریوهای پیچیده خراب کند.

اگر مشکل فقط روی یک اینترنت یا Router خاص دیده می‌شود، REFER سالم و خراب را با Packet Capture مقایسه کنید.

Firewall باید REFER را عبور دهد

بعضی Firewallها فقط Methodهای رایج مانند REGISTER، INVITE، ACK و BYE را در نظر می‌گیرند.

اگر REFER یا NOTIFY توسط SIP Inspection یا SBC Policy محدود شود، تماس عادی کاملاً کار می‌کند اما Transfer شکست می‌خورد.

در Trace دو طرف Firewall بررسی کنید REFER واقعاً عبور کرده است یا نه.

مرحله یازدهم: Route تماس مقصد را جداگانه تست کنید

قبل از اینکه Transfer را مقصر بدانید، از همان Yealink یک تماس عادی مستقیم به مقصد Transfer برقرار کنید.

مرحله دوازدهم: Firmware Behavior را بررسی کنید

تنظیمات Transfer و رفتار Softkey بین نسل‌های Firmware ممکن است تغییر کند.

اگر مشکل دقیقاً بعد از Update Firmware شروع شده است، قبل از Downgrade این موارد را مقایسه کنید:

Transfer Mode.

Semi-attended Setting.

Refer-To Contact Behavior.

DSS Key Mode.

On-hook Transfer.

Packet Capture قبل و بعد از Update.

تغییر Firmware بدون Trace می‌تواند علت واقعی را پنهان کند.

Auto Provisioning ممکن است Transfer Mode را بازنویسی کند

اگر تنظیمات را در Web UI اصلاح می‌کنید ولی بعد از Reboot دوباره به حالت قبل برمی‌گردند، MAC CFG، Common CFG یا Device Template را بررسی کنید.

مثلاً ممکن است PBX Template دائماً این مقدار را Push کند:

transfer.dsskey_deal_type = 2

در این حالت تغییر دستی تلفن فقط تا Provisioning بعدی باقی می‌ماند.

سناریوی اول: Blind Transfer اصلاً انجام نمی‌شود

ابتدا تماس مستقیم به مقصد را تست کنید. بعد بررسی کنید REFER از Yealink خارج می‌شود یا نه.

اگر REFER وجود ندارد، تنظیمات Phone و Transfer Mode را بررسی کنید.

اگر REFER وجود دارد ولی PBX 403، 404 یا 405 می‌دهد، مشکل Server-side را حل کنید.

اگر REFER پذیرفته می‌شود ولی NOTIFY خطا برمی‌گرداند، نتیجه Referred Call را بررسی کنید.

سناریوی دوم: Blind سالم است ولی Attended Transfer خراب است

این حالت Replaces را در اولویت قرار می‌دهد.

تماس دوم را در PCAP پیدا کنید و Call-ID و Tagها را با Replaces مقایسه کنید.

همچنین Contact و Refer-To را قبل و بعد از SBC بررسی کنید.

سناریوی سوم: Semi-attended کار نمی‌کند ولی Attended سالم است

تنظیم `transfer.semi_attend_tran_enable` و رفتار Firmware را بررسی کنید.

زمان فشار Transfer را نیز مهم بدانید: Semi-attended زمانی انجام می‌شود که مقصد هنوز فقط Ringback دارد و Answer نکرده است.

سناریوی چهارم: انتقال انجام می‌شود ولی تماس قطع می‌شود

ابتدا مشخص کنید کدام تماس قطع می‌شود.

اگر فقط انتقال‌دهنده خارج می‌شود و B و C به هم وصل می‌شوند، این رفتار طبیعی Transfer است.

اگر همه Channelها قطع می‌شوند، SIP Trace، NOTIFY نتیجه Transfer و PBX Log را بررسی کنید.

سناریوی پنجم: Transfer به داخلی کار می‌کند ولی به شماره خارجی نه

Outbound Route، Permission، Class of Service، Trunk Policy و Format شماره داخل Refer-To را بررسی کنید.

ممکن است User اجازه Dial عادی خارجی داشته باشد ولی Transfer کردن یک تماس به مقصد خارجی توسط PBX ممنوع شده باشد.

سناریوی ششم: انتقال خارجی به داخلی خراب است

اگر تماس داخلی به داخلی سالم است ولی تماس ورودی از Trunk منتقل نمی‌شود، PBX و SBC ممکن است Transfer Policy یا Dialog Handling متفاوتی برای Trunk داشته باشند.

تماس سالم و خراب را کنار هم Capture کنید و تفاوت Refer-To، Contact و Replaces را مقایسه کنید.

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

Transfer Mode via DSS Key احتمالاً روی Blind Transfer قرار دارد.

اگر انتظار Consultation دارید، Mode را روی Attended قرار دهید؛ البته پس از بررسی سازگاری PBX.

سناریوی هشتم: بعد از شکست Transfer تماس اصلی از بین می‌رود

گزینه‌های Resume/Keep Session Yealink را بررسی کنید، اما علت Server-side را نیز پیدا کنید.

این تنظیم‌ها برای Recovery تجربه کاربر هستند، نه جایگزین حل خطای REFER.

سناریوی نهم: Feature Code کار می‌کند ولی TRANSFER Key نه

این یکی از واضح‌ترین نشانه‌های مشکل Native SIP Transfer است.

Feature Code در PBX با DTMF مدیریت می‌شود، در حالی که کلید Transfer Yealink معمولاً از REFER استفاده می‌کند.

REFER، Refer-To، Replaces و Permission را بررسی کنید.

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

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

فرق Blind و Attended Transfer در Yealink چیست؟

در Blind Transfer تماس بدون مشورت مستقیماً به مقصد فرستاده می‌شود. در Attended Transfer ابتدا با مقصد تماس گرفته و صحبت می‌کنید و سپس انتقال را کامل می‌کنید. Yealink همچنین Semi-attended Transfer را برای تکمیل انتقال هنگام Ringback پشتیبانی می‌کند.

REFER در انتقال تماس Yealink چیست؟

REFER یک SIP Method برای درخواست ارجاع تماس یا Resource به مقصد دیگر است. Yealink برای Call Transfer از REFER استفاده می‌کند و مقصد معمولاً داخل Refer-To قرار می‌گیرد.

Replaces چرا در Attended Transfer مهم است؟

Replaces مشخص می‌کند Dialog جدید باید کدام Dialog موجود را جایگزین کند. اگر Call-ID یا Tagها با Session واقعی تطابق نداشته باشند، Attended Transfer می‌تواند شکست بخورد حتی اگر Blind Transfer سالم باشد.

چرا Blind Transfer کار می‌کند ولی Attended Transfer نه؟

چون Blind Transfer معمولاً REFER ساده دارد اما Attended Transfer به Replaces، Consultation Dialog و Contact صحیح وابسته است. Replaces، SBC و تنظیم Refer-To Contact را بررسی کنید.

چرا دکمه BLF تماس را فوری منتقل می‌کند؟

احتمالاً Transfer Mode via DSS Key روی Blind Transfer قرار دارد. Yealink امکان انتخاب New Call، Attended Transfer و Blind Transfer را برای DSS/BLF Key فراهم می‌کند.

چرا PBX Feature Code کار می‌کند ولی دکمه Transfer کار نمی‌کند؟

Feature Code می‌تواند داخل PBX و با DTMF پردازش شود، در حالی که دکمه Transfer Yealink معمولاً SIP REFER می‌فرستد. این تفاوت نشان می‌دهد REFER یا Interoperability باید بررسی شود.

پاسخ 202 به REFER خطاست؟

لزوماً خیر. RFC 3515 اولیه از 202 Accepted استفاده می‌کرد، اما RFC 7647 آن را Deprecated کرده و 200 OK را جایگزین کرده است. پیاده‌سازی‌های Legacy ممکن است هنوز 202 برگردانند.

چرا بعد از Transfer تماس اصلی هم قطع می‌شود؟

اگر انتقال موفق باشد، خارج‌شدن کاربر انتقال‌دهنده طبیعی است. اگر تماس مقصد هم قطع می‌شود، NOTIFY نتیجه REFER، PBX Log و Replaces را بررسی کنید.

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

معمولاً خیر. ابتدا Transfer Mode، REFER، Replaces، PBX Policy، Feature Code، SBC و Provisioning را بررسی کنید. Factory Reset اغلب اطلاعات عیب‌یابی را پاک می‌کند بدون اینکه علت Server-side را حل کند.

جمع‌بندی

برای رفع مشکل انتقال تماس در Yealink ابتدا مشخص کنید Blind، Semi-attended یا Attended Transfer خراب است. اگر همه آن‌ها مشکل دارند، REFER پایه، Permission و Routing را بررسی کنید. اگر فقط Attended Transfer شکست می‌خورد، Replaces و Consultation Dialog در اولویت قرار می‌گیرند.

در Packet Capture فقط خود REFER را نبینید؛ Refer-To، پاسخ PBX و NOTIFYهای Event برابر refer را هم بررسی کنید. پذیرش REFER به معنی موفقیت نهایی انتقال نیست و نتیجه Referred Call می‌تواند داخل SIP Fragment گزارش شود.

اگر Feature Code مرکز تلفن کار می‌کند ولی کلید Transfer Yealink نه، مشکل را در مسیر Native SIP Transfer جست‌وجو کنید. در Asterisk نیز Core Feature Code Transfer مستقل از انتقال Native PJSIP است و همین تست می‌تواند محل خرابی را بسیار سریع محدود کند.

در نهایت Firmware و Auto Provisioning را بررسی کنید. تنظیماتی مانند DSS Transfer Mode، Semi-attended Transfer، Refer-To Contact و رفتار On-hook ممکن است توسط Template مرکزی بازنویسی شوند. با مقایسه یک Trace سالم و خراب معمولاً می‌توان بدون Factory Reset مشخص کرد ایراد از تلفن، PBX، SBC یا Policy شبکه است.