Amir Jabbari
در این راهنما ابتدا تفاوت انتقال مستقیم یا Blind Transfer با انتقال مشورتی یا Consultative/Attended Transfer را روشن می‌کنیم. سپس تنظیمات تلفن، Softkey State، پیام REFER، هدر Replaces، سیاست انتقال سمت PBX و در نهایت مشکلات صوت و مذاکره دوباره Codec بعد از Transfer را بررسی می‌کنیم.
تشخیص سریع: اگر دکمه Transfer اصلاً ظاهر نمی‌شود، ابتدا تنظیمات خود Cisco MPP و Softkeyها را بررسی کنید. اگر REFER ارسال می‌شود ولی PBX آن را رد می‌کند، مشکل سمت Policy یا Dialplan است. اگر Transfer کامل می‌شود اما صدا خراب می‌شود، باید SDP، Codec، RTP و re-INVITE را بررسی کنید.
Blind Transfer و Consultative Transfer چه فرقی دارند؟
در انتقال Blind یا مستقیم، تماس‌گیرنده را بدون صحبت قبلی با مقصد به شماره دیگری می‌فرستید. مثلاً مشتری با داخلی ۱۰۰ صحبت می‌کند و داخلی ۱۰۰ تماس را مستقیم به داخلی ۲۰۰ منتقل می‌کند.
در این حالت اپراتور معمولاً قبل از تکمیل انتقال با داخلی ۲۰۰ صحبت نمی‌کند.
در انتقال Consultative یا Attended، ابتدا تماس اصلی روی Hold قرار می‌گیرد، اپراتور با مقصد جدید تماس می‌گیرد، با او صحبت می‌کند و سپس دو تماس را به یکدیگر متصل می‌کند.
| نوع انتقال | روش | پیچیدگی SIP |
|---|---|---|
| Blind Transfer | انتقال مستقیم بدون صحبت با مقصد | معمولاً ساده‌تر و مبتنی بر REFER |
| Consultative / Attended | تماس دوم برقرار می‌شود، سپس دو طرف به هم وصل می‌شوند | معمولاً به Dialog دوم و Replaces نیاز دارد |
اول مطمئن شوید خود Cisco MPP انتقال تماس را غیرفعال نکرده است
در تلفن‌های Cisco MPP، Blind Transfer و Attended Transfer دو سرویس مستقل هستند.
از رابط مدیریتی تلفن وارد مسیر زیر شوید:
Admin Login → Advanced → Voice → Phone
در بخش Supplementary Services این دو گزینه را بررسی کنید:
Attn Transfer Serv
Blind Transfer Serv
در حالت معمول هر دو باید روی Yes باشند.
برای Provisioning XML نیز Cisco ساختار زیر را مستند کرده است:
<Attn_Transfer_Serv ua="na">Yes</Attn_Transfer_Serv>
<Blind_Transfer_Serv ua="na">Yes</Blind_Transfer_Serv>اگر Provisioning Server دارید، فقط تنظیم دستی تلفن را بررسی نکنید. ممکن است cfg.xml بعد از Resync دوباره یکی از این قابلیت‌ها را غیرفعال کند.
چرا دکمه Transfer یا BlindXfer روی تلفن دیده نمی‌شود؟
وجود قابلیت Transfer به این معنا نیست که Softkey آن در همه وضعیت‌های تماس نمایش داده شود.
Cisco MPP برای هر وضعیت تماس یک Softkey List جدا دارد. مثلاً کلید bxfer برای Blind Transfer در وضعیت Connected استفاده می‌شود و نیاز دارد Blind Transfer Service فعال باشد.
کلید xfer مربوط به انتقال attended است و در Stateهایی مثل Connected و Start-Xfer قابل استفاده است.
پس اگر کاربر می‌گوید «Transfer قبلاً بود ولی الان نیست»، Connected Key List را بررسی کنید.
یک نمونه معمول می‌تواند شامل این موارد باشد:
hold;endcall;conf;xfer;toggle;bxfer;confLx;xferLx;park;اگر xfer یا bxfer از Connected Key List حذف شده باشد، ممکن است سرویس فعال باشد اما کاربر Softkey لازم را نبیند.
Blind Transfer در SIP چه اتفاقی ایجاد می‌کند؟
در بسیاری از پیاده‌سازی‌های SIP، انتقال تماس با پیام REFER انجام می‌شود.
فرض کنید A با B تماس دارد و B می‌خواهد A را به C منتقل کند. B یک REFER به PBX یا طرف SIP مسئول تماس می‌فرستد و مقصد انتقال در Header مربوط به Refer-To مشخص می‌شود.
یک نمونه ساده و آموزشی:
REFER sip:pbx.example.net SIP/2.0
Refer-To: <sip:200@pbx.example.net>این نمونه برای درک ساختار است و Headerهای کامل یک پیام واقعی حذف شده‌اند.
اگر PBX انتقال را می‌پذیرد، پاسخ‌هایی مانند 202 Accepted در جریان REFER رایج هستند و نتیجه Transfer می‌تواند از طریق SIP NOTIFY به Endpoint گزارش شود.
Consultative Transfer چرا پیچیده‌تر است؟
در Consultative Transfer، تلفن قبل از انتقال نهایی با مقصد دوم یک تماس جدا می‌سازد.
در این لحظه دو Dialog داریم:
تماس اول میان تماس‌گیرنده و اپراتور، و تماس دوم میان اپراتور و مقصد Transfer.
بعد از اینکه اپراتور تصمیم به تکمیل Transfer می‌گیرد، سیستم باید این دو Dialog را طوری به هم مرتبط کند که اپراتور از وسط تماس حذف شود.
اینجاست که SIP Replaces اهمیت پیدا می‌کند.
هدر Replaces چه کاری انجام می‌دهد؟
RFC مربوط به SIP Replaces این Header را برای جایگزین‌کردن یک Dialog موجود با Dialog جدید تعریف کرده است؛ یکی از کاربردهای اصلی آن Attended Transfer است.
در یک Consultative Transfer، Refer-To ممکن است اطلاعات Dialog تماس دوم را به‌شکل Replaces همراه داشته باشد.
نمونه ساده‌شده:
Refer-To: <sip:200@pbx.example.net?Replaces=CALL-ID%3Bto-tag%3Dabc%3Bfrom-tag%3Dxyz>PBX از Call-ID و Tagها برای پیدا کردن Dialog مربوطه استفاده می‌کند.
اگر SBC، PBX یا SIP Proxy اطلاعات Replaces را حذف یا تغییر دهد، Blind Transfer ممکن است کاملاً سالم باشد اما Attended Transfer شکست بخورد.
چطور بفهمیم مشکل از REFER است؟
یک SIP Capture بگیرید و فقط جریان انتقال را بررسی کنید.
در Wireshark:
sip.Method == "REFER"برای دیدن کل SIP Flow:
sipاگر با فشردن Transfer هیچ REFER دیده نمی‌شود، مشکل احتمالاً قبل از PBX و در رفتار تلفن، Softkey یا Transfer Service است.
اگر REFER دیده می‌شود، پاسخ PBX مسیر بعدی را مشخص می‌کند.
کد پاسخ PBX چه چیزی درباره خطای Transfer می‌گوید؟
| پاسخ | برداشت اولیه | چه چیزی را بررسی کنیم؟ |
|---|---|---|
| 202 Accepted | PBX پردازش REFER را پذیرفته است | NOTIFY و نتیجه تماس مقصد |
| 403 Forbidden | انتقال از نظر Policy مجاز نیست یا مقصد ممنوع است | PBX Policy، Class of Service و allow_transfer |
| 404 Not Found | مقصد یا URI انتقال پیدا نشده است | Refer-To، Dialplan و Route |
| 481 | Dialog مورد اشاره پیدا نشده است | Call-ID، Tagها و Replaces |
| Timeout | مسیر یا مقصد Transfer پاسخ نداده است | Routing، Firewall، SBC و مقصد |
این جدول نقطه شروع است؛ کد نهایی باید همراه SIP Flow و منطق PBX بررسی شود.
PBX Policy؛ وقتی خود سرور Transfer را ممنوع کرده است
ممکن است Cisco MPP کاملاً درست REFER ارسال کند، اما PBX اجازه اجرای Transfer را ندهد.
در Asterisk/PJSIP گزینه allow_transfer مشخص می‌کند SIP REFER Transfer برای Endpoint مجاز باشد یا نه.
نمونه:
[100]
type=endpoint
allow_transfer=yesاگر مقدار روی No باشد، REFERهای Transfer برای آن Endpoint مجاز نیستند.
این تنظیم را بدون بررسی امنیت تغییر ندهید. Transfer می‌تواند باعث ایجاد تماس جدید به مقصد دیگری شود و PBX باید فقط Destinationهای مجاز را قبول کند.
چرا Blind Transfer کار می‌کند ولی Attended Transfer نه؟
این علامت بسیار مهم است.
وقتی Blind Transfer سالم است، معمولاً می‌دانیم که Softkey پایه، REFER و حداقل بخشی از Policy سمت PBX کار می‌کنند.
اگر فقط Consultative Transfer خراب است، بیشتر روی این موارد تمرکز کنید:
تماس دوم واقعاً Establish شده باشد، PBX هر دو Dialog را بشناسد، Replaces صحیح باشد، Call-ID و Tagها در مسیر SBC تغییر ناسازگار نکنند و Policy مربوط به Attended Transfer یا Remote Transfer اجازه اجرا داشته باشد.
در Asterisk، Remote Attended Transfer پیچیده‌تر است؛ چون ممکن است Dialog دوم روی یک SIP Server دیگر قرار داشته باشد و PBX نتواند آن را به‌عنوان Local Dialog پیدا کند.
Remote Attended Transfer و external_replaces در Asterisk
در انتقال مشورتی‌ای که تماس دوم روی یک SIP Server دیگر قرار دارد، Asterisk ممکن است با Remote Attended Transfer روبه‌رو شود.
در این حالت Refer-To حاوی Replaces است اما Dialog مورد اشاره داخل همان Asterisk نیست.
Asterisk برای چنین سناریویی می‌تواند به Extension ویژه‌ای با نام external_replaces در Dialplan مراجعه کند تا مشخص شود انتقال به مقصد بیرونی مجاز است یا نه.
این محدودیت دلیل امنیتی دارد؛ PBX نباید هر REFER دریافتی را بدون کنترل به یک دامنه یا مقصد خارجی تبدیل به تماس کند.
بعد از REFER چه چیزی را در NOTIFY ببینیم؟
پذیرفته‌شدن REFER پایان ماجرا نیست.
PBX می‌تواند با NOTIFY نتیجه پیشرفت Transfer را به Endpoint اعلام کند.
بنابراین اگر REFER با 202 Accepted پاسخ گرفته اما Cisco هنوز Transfer Failed نشان می‌دهد، NOTIFYهای بعدی را بررسی کنید.
در Wireshark:
sip.Method == "NOTIFY"Body یا Event مربوط به NOTIFY را کنار نتیجه تماس مقصد بررسی کنید.
Transfer انجام می‌شود ولی تماس بعد از انتقال قطع می‌شود
در این سناریو Signaling اولیه Transfer ممکن است موفق باشد ولی Dialog جدید پایدار نمی‌ماند.
سه بخش را جداگانه بررسی کنید:
اول، BYE و Session پایان‌یافته را ببینید تا مشخص شود کدام سمت تماس را قطع کرده است.
دوم، SDP تماس جدید را بررسی کنید تا IP و RTP Portهای درست اعلام شده باشند.
سوم، Codec انتخاب‌شده را با قابلیت دو Endpoint نهایی مقایسه کنید.
Codec Renegotiation بعد از Transfer چرا مهم است؟
بعد از Hold، Transfer یا تغییر مسیر تماس، SIP می‌تواند re-INVITE و SDP جدید ایجاد کند.
این SDP ممکن است Codec یا مسیر Media را دوباره مذاکره کند.
اگر Endpoint اولیه مثلاً G.711 و G.729 را پشتیبانی کند اما مقصد Transfer فقط مجموعه محدود دیگری داشته باشد، PBX باید اشتراک مناسب Codecها را پیدا کند یا Transcoding انجام دهد.
اگر Signaling سالم است اما تماس جدید Audio ندارد، SDP قبل و بعد از Transfer را با هم مقایسه کنید.
در Wireshark عبارت‌های زیر را بررسی کنید:
sip || sdp || rtpTransfer موفق است اما بعدش صدای یک‌طرفه داریم
این بخش در MPP اهمیت ویژه‌ای دارد، چون Cisco برای یک سناریوی مشخص راه‌حل رسمی مستند کرده است.
در راهنمای فعلی MPP، پارامتر SSRC Reset on Rx RE-INVITE برای جلوگیری از خطای انتقالی معرفی شده که بعد از re-INVITE باعث می‌شود فقط یکی از طرفین صدا را بشنود.
Cisco اشاره می‌کند این حالت بیشتر در تماس‌های طولانی و بعضی تماس‌های سه‌طرفه دیده می‌شود.
مسیر تنظیم در تلفن:
Voice → SIP → RTP Parameters
و سپس:
SSRC Reset on Rx RE-INVITE = Yes
در Provisioning:
<SSRC_Reset_on_Rx_RE-INVITE ua="na">Yes</SSRC_Reset_on_Rx_RE-INVITE>این گزینه را نباید به‌عنوان راه‌حل همه مشکلات Transfer فعال کنید. اگر REFER با 403 رد می‌شود یا مقصد اشتباه است، SSRC هیچ ارتباطی با مشکل ندارد.
SSRC چیست و چرا در Transfer اهمیت پیدا می‌کند؟
SSRC شناسه منبع RTP است. در بعضی جریان‌های رسانه‌ای، بعد از ایجاد Session جدید یا re-INVITE ممکن است Endpoint مقابل انتظار Media Source جدیدی داشته باشد.
اگر در شرایط خاص SSRC قبلی حفظ شود، سمت مقابل ممکن است RTP جدید را به‌شکل مورد انتظار پردازش نکند.
به همین دلیل Cisco امکان Reset آن را هنگام re-INVITE فراهم کرده است.
اگر فقط تماس‌های طولانی بعد از Transfer یک‌طرفه می‌شوند
این علامت دقیقاً همان سناریویی است که بررسی SSRC Reset ارزش بالاتری پیدا می‌کند.
یک تماس کوتاه و یک تماس طولانی را با یک مسیر Transfer یکسان آزمایش کنید.
اگر تماس کوتاه سالم است اما تماس طولانی بعد از Transfer Media یک‌طرفه دارد، SIP re-INVITE و RTP SSRC را مقایسه کنید.
در Asterisk چطور REFER را ببینیم؟
برای عیب‌یابی موقت PJSIP Logger را فعال کنید:
pjsip set logger onیک Blind Transfer و یک Attended Transfer انجام دهید و REFER، Refer-To، Replaces و NOTIFY را ذخیره کنید.
بعد Logger را خاموش کنید:
pjsip set logger offاگر Asterisk فقط بعضی مقصدها را Transfer نمی‌کند
در این حالت به‌جای تلفن، Dialplan و Context را بررسی کنید.
ممکن است انتقال داخلی به ۲۰۰ مجاز باشد اما REFER به یک شماره شهری یا SIP Domain دیگر توسط Policy رد شود.
Context Endpoint و Destination Transfer را با تماس معمولی مقایسه کنید.
Remote Attended Transfer نیز ممکن است نیازمند بررسی جداگانه external_replaces باشد.
Softkey State؛ چرا Transfer در یک تماس هست و در تماس دیگر نیست؟
Programmable Softkeys در Cisco MPP به Call State وابسته‌اند.
اگر Provisioning سفارشی دارید، ممکن است `xfer` فقط در Connected Key List باشد اما در وضعیت دیگری که انتظارش را دارید قرار نگرفته باشد.
همچنین اگر تماس دوم برای Consultative Transfer ساخته نشده یا State تلفن به Start-Xfer نرسد، رفتار Softkey متفاوت خواهد بود.
بنابراین قبل از Factory Reset، Key Listها را با Profile پیش‌فرض مقایسه کنید.
اگر Transfer بعد از آپدیت Firmware خراب شده است
ابتدا بررسی کنید آیا Provisioning Profile نیز همراه Firmware تغییر کرده است.
گاهی بعد از Upgrade، خود Firmware مقصر نیست و cfg.xml جدید Connected Key List یا Supplementary Services را بازنویسی کرده است.
این موارد را قبل و بعد از Upgrade مقایسه کنید:
🔹 Attn Transfer Serv
🔹 Blind Transfer Serv
🔹 Connected Key List
🔹 SIP Proxy و Transport
🔹 Codec List
🔹 SSRC Reset on Rx RE-INVITE
یک روش سریع برای پیدا کردن محل شکست
| نشانه | احتمال بیشتر | اولین بررسی |
|---|---|---|
| Transfer Softkey نیست | Softkey/Service غیرفعال | Connected Key List و Supplementary Services |
| با زدن Transfer هیچ REFER نیست | مشکل Endpoint یا State | SIP Capture و Softkey State |
| REFER → 403 | PBX Policy | allow_transfer و Dialplan |
| REFER → 202 ولی Transfer Fail | مقصد نهایی یا NOTIFY | NOTIFY و تماس مقصد |
| Blind سالم، Consultative خراب | Replaces/Dialog Mapping | Refer-To و Replaces |
| Transfer کامل می‌شود ولی تماس قطع می‌شود | Dialog، Route یا SDP | BYE، re-INVITE و SDP |
| بعد از Transfer صدای یک‌طرفه | RTP/SDP/SSRC | Codec، RTP و SSRC Reset |
Packet Capture کامل برای Transfer چگونه گرفته شود؟
Capture را قبل از فشردن Transfer شروع کنید.
برای Consultative Transfer، تماس دوم و تکمیل Transfer را نیز کامل داخل Capture نگه دارید.
بعد این ترتیب را بررسی کنید:
۱. Hold/re-INVITE تماس اول
۲. INVITE تماس مشورتی به مقصد جدید
۳. Answer تماس دوم
۴. REFER و Refer-To
۵. Replaces در Attended Transfer
۶. پاسخ REFER
۷. NOTIFY
۸. re-INVITE/SDP پس از اتصال نهایی
۹. RTP بین دو طرف باقی‌مانده
این جریان تقریباً همیشه مشخص می‌کند Transfer در Signaling خراب شده یا Media.
چه زمانی Factory Reset کنیم؟
برای خطای Transfer تقریباً هیچ‌وقت اولین اقدام Factory Reset نیست.
اگر REFER با 403 رد شده، Reset PBX Policy را تغییر نمی‌دهد.
اگر Replaces توسط SBC خراب می‌شود، Reset تلفن راه‌حل نیست.
اگر RTP بعد از Transfer یک‌طرفه است، ابتدا SDP و SSRC را بررسی کنید.
Reset بیشتر وقتی ارزش دارد که Provisioning قدیمی یا تنظیمات محلی ناسازگار روی Endpoint باقی مانده باشند و این موضوع با مقایسه یک تلفن سالم تأیید شده باشد.
پرسش‌های رایج
Blind Transfer و Consultative Transfer در Cisco چه فرقی دارند؟
در Blind Transfer تماس بدون صحبت قبلی با مقصد منتقل می‌شود. در Consultative Transfer ابتدا با مقصد دوم صحبت می‌کنید و بعد دو تماس به هم متصل می‌شوند.
چرا دکمه Transfer روی Cisco MPP دیده نمی‌شود؟
Attn Transfer Serv یا Blind Transfer Serv ممکن است غیرفعال باشد یا `xfer` و `bxfer` از Softkey List مربوط به وضعیت تماس حذف شده باشند.
REFER در Transfer چه کاری انجام می‌دهد؟
REFER به SIP Server می‌گوید تماس را به مقصد مشخص‌شده در Refer-To منتقل کند. نتیجه پردازش انتقال می‌تواند با NOTIFY به Endpoint گزارش شود.
Replaces چه زمانی استفاده می‌شود؟
Replaces بیشتر در Attended Transfer اهمیت دارد؛ جایی که Dialog تماس مشورتی باید جایگزین Dialog قبلی شود.
چرا Blind Transfer کار می‌کند ولی Attended Transfer نه؟
در این حالت REFER پایه احتمالاً سالم است اما Dialog Mapping، Replaces، تماس مشورتی یا Policy مربوط به Attended/Remote Transfer باید بررسی شود.
چرا بعد از Transfer صدا یک‌طرفه می‌شود؟
SDP، RTP، Codec و re-INVITE را بررسی کنید. Cisco برای بعضی سناریوهای MPP پارامتر SSRC Reset on Rx RE-INVITE را برای جلوگیری از خطای یک‌طرفه شدن صدا بعد از Transfer مستند کرده است.
در Asterisk چه تنظیمی می‌تواند Transfer را ببندد؟
در PJSIP گزینه `allow_transfer` مشخص می‌کند SIP REFER Transfer برای Endpoint مجاز باشد یا نه.
REFER با 202 Accepted آمده ولی Transfer انجام نشده؛ چرا؟
202 فقط یعنی PBX پردازش REFER را پذیرفته است. نتیجه واقعی تماس مقصد و NOTIFYهای بعدی را نیز بررسی کنید.
جمع‌بندی
برای رفع مشکل انتقال تماس Cisco، ابتدا مشخص کنید Blind Transfer خراب است یا Consultative Transfer. بعد بررسی کنید Softkey و سرویس Transfer در خود MPP فعال باشند. اگر REFER از تلفن خارج شد، از همان‌جا تمرکز را به PBX Policy، Refer-To و پاسخ‌های SIP منتقل کنید.
اگر فقط Consultative Transfer شکست می‌خورد، Replaces و Dialog Mapping اهمیت بیشتری دارند. اگر Signaling انتقال موفق است ولی صدا خراب می‌شود، مرحله بعد SDP، Codec، RTP و SSRC است. این تفکیک جلوی Reset و تغییرهای تصادفی را می‌گیرد و معمولاً نقطه خرابی را خیلی سریع‌تر مشخص می‌کند.
Transfer روی تلفن درست تنظیم شده اما PBX هنوز REFER را رد می‌کند؟
اگر تماس‌های عادی سالم‌اند ولی Blind یا Consultative Transfer خطا می‌دهند، مشکل معمولاً با تغییر تصادفی Firmware حل نمی‌شود. SIP Trace، Policy سرور، Refer-To/Replaces و مسیر RTP باید کنار هم بررسی شوند تا مشخص شود Transfer در تلفن، PBX یا Media متوقف شده است.
اگر مرکز تلفن Asterisk، FreePBX، 3CX یا SIP Server شما روی سرور اجرا می‌شود، می‌توانید تنظیمات Transfer، Dialplan، Firewall و Media را به‌صورت یکپارچه بررسی و اصلاح کنید.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
دیدگاه‌ها (۰)