Amir Jabbari
در یک تماس ورودی ممکن است Headerهای From، P-Asserted-Identity، Remote-Party-ID و گاهی P-Preferred-Identity مقادیر متفاوتی داشته باشند. علاوه بر این، PBX، SIP Trunk، SBC یا Provider ممکن است شماره را هنگام عبور از شبکه تغییر دهد؛ سپس خود تلفن نیز ممکن است همان شماره را با Local Directory تطبیق دهد و نام ذخیره‌شده دیگری را نمایش دهد.
در این آموزش ابتدا مشخص می‌کنیم Yealink Caller ID را از کجا می‌خواند، بعد با Packet Capture مقدار واقعی SIP Headerها را بررسی می‌کنیم و در ادامه تنظیم Caller ID Source، PAI، RPID، Privacy، فرمت شماره کشور، دفترچه تلفن، Forward و Transfer و تنظیمات Asterisk/PJSIP را مرحله‌به‌مرحله بررسی می‌کنیم.
اول مشخص کنید چه چیزی اشتباه نمایش داده می‌شود
| علامت | مظنون اصلی |
|---|---|
| شماره کاملاً اشتباه است | SIP Header، PBX یا Provider |
| شماره درست ولی نام اشتباه است | Local Directory یا Display Name |
| Anonymous نمایش داده می‌شود | Privacy، Caller ID Source یا Header خالی |
| شماره داخلی به‌جای موبایل نمایش داده می‌شود | From/PAI Priority یا PBX Rewrite |
| قبل از Answer درست و بعد از Answer عوض می‌شود | Connected Line Identification |
| بعد از Transfer شماره شخص دیگری نمایش داده می‌شود | Connected Identity، UPDATE یا PBX |
Caller ID در SIP فقط یک فیلد نیست
در یک تماس SIP ممکن است چند Identity مختلف داخل همان INVITE وجود داشته باشد.
نمونه:
INVITE sip:201@pbx.example.local SIP/2.0
From: "Customer" <sip:09121234567@provider.example>
P-Asserted-Identity: "+989121234567" <sip:+989121234567@provider.example>
Remote-Party-ID: "Customer" <sip:9121234567@provider.example>در این مثال سه فرمت متفاوت از یک تماس‌گیرنده وجود دارد:
| Header | شماره |
|---|---|
| From | 09121234567 |
| PAI | +989121234567 |
| RPID | 9121234567 |
اگر تلفن روی PAI تنظیم شده باشد، نسخه +98 نمایش داده می‌شود. اگر روی From باشد، 09 نمایش داده می‌شود. بنابراین همیشه «شماره اشتباه» به معنی خرابی Phone نیست؛ ممکن است Phone دقیقاً همان Source انتخاب‌شده را نمایش دهد.
Yealink Caller ID را از چه Headerهایی می‌خواند؟
در مستندات فعلی Yealink، Calling Line Identification یا CLIP می‌تواند از Headerهایی مانند From، P-Asserted-Identity و Remote-Party-ID استخراج شود. در Firmwareهای جدید امکان استفاده از P-Preferred-Identity و ترتیب سفارشی نیز وجود دارد.
پارامتر اصلی:
account.X.cid_sourceمقادیر Caller ID Source در Yealink
| مقدار | اولویت Caller ID |
|---|---|
| 0 | FROM |
| 1 | PAI |
| 2 | PAI → FROM |
| 3 | RPID → PAI → FROM |
| 4 | PAI → RPID → FROM |
| 5 | RPID → FROM |
| 6 | Preference سفارشی |
مقدار پیش‌فرض در مستند فعلی Yealink برابر 0 یعنی From است، اما Provider یا Auto Provisioning ممکن است مقدار دیگری روی تلفن اعمال کرده باشد.
Caller ID Source را از Web UI بررسی کنید
در بسیاری از تلفن‌های رومیزی Yealink مسیر تنظیمات به شکل زیر است:
Account → Advanced → Caller ID Source
اگر شماره اشتباه نمایش داده می‌شود، Source را فقط بر اساس حدس تغییر ندهید. ابتدا Packet Capture بگیرید و ببینید PBX شماره صحیح را داخل کدام Header ارسال می‌کند.
مثلاً اگر شماره درست داخل PAI است
فرض کنید INVITE چنین است:
From: "Trunk" <sip:02191302467@pbx.local>
P-Asserted-Identity: "Iranica" <sip:+982191302467@pbx.local>ولی Yealink روی:
account.1.cid_source = 0باشد، Phone مقدار From را نمایش می‌دهد.
اگر ساختار PBX شما PAI را Source معتبر Caller ID در نظر گرفته است، می‌توان آن Account را مثلاً روی PAI-FROM قرار داد:
account.1.cid_source = 2در این حالت Phone ابتدا PAI را بررسی می‌کند و در صورت نبودن آن سراغ From می‌رود.
P-Asserted-Identity یا PAI دقیقاً چیست؟
P-Asserted-Identity در RFC 3325 برای انتقال Identity تأییدشده داخل یک شبکه مورد اعتماد تعریف شده است.
یعنی معمولاً Proxy، PBX یا Provider بعد از اینکه هویت تماس‌گیرنده را می‌شناسد می‌تواند آن Identity را در PAI قرار دهد.
نمونه:
P-Asserted-Identity: "Ali" <sip:+989121234567@operator.example>در بسیاری از SIP Trunkها PAI قابل اعتمادتر از Display Name داخل From است، اما این موضوع به معماری Provider و Trust Domain بستگی دارد.
From همیشه بهترین Caller ID نیست
Header From بخشی اصلی از SIP Dialog است، اما ممکن است PBX برای Routing یا Presentation مقدار دیگری داخل آن قرار دهد.
مثلاً Provider ممکن است:
From را برابر شماره اصلی Trunk قرار دهد،
و شماره واقعی Calling Party را داخل PAI بفرستد.
اگر Phone از From استفاده کند، تمام تماس‌ها ممکن است با یک شماره ثابت نمایش داده شوند.
Remote-Party-ID چیست؟
Remote-Party-ID یا RPID در بسیاری از PBXها و سیستم‌های قدیمی‌تر برای حمل Identity استفاده شده و Yealink همچنان امکان خواندن آن را فراهم می‌کند.
نمونه:
Remote-Party-ID: "Customer" <sip:09121234567@pbx.local>اگر PBX شما RPID را Source اصلی می‌فرستد، Caller ID Source باید با همان معماری هماهنگ باشد.
Preference Mode چه زمانی کاربرد دارد؟
در Firmwareهای فعلی Yealink اگر:
account.1.cid_source = 6باشد، می‌توان ترتیب Headerها را سفارشی تعریف کرد.
پارامتر:
sip.cid_source.preference = P-Preferred-Identity,P-Asserted-Identity,Remote-Party-ID,Fromاین قابلیت زمانی مفید است که Provider چند Header ارسال می‌کند و می‌خواهید Priority دقیقی برای همه تلفن‌ها تعریف کنید.
مرحله اول عیب‌یابی واقعی: Packet Capture بگیرید
قبل از تغییر Caller ID Source، یک تماس ورودی آزمایشی ایجاد کنید و Packet Capture بگیرید.
در Wireshark:
sip.Method == "INVITE"INVITE مربوط به تماس ورودی را باز کنید و این Headerها را یادداشت کنید:
From:
P-Asserted-Identity:
Remote-Party-ID:
P-Preferred-Identity:
Privacy:
Diversion:
History-Info:یک جدول ساده برای مقایسه بسازید
| Source | مقدار دریافتی |
|---|---|
| From | ثبت شود |
| PAI | ثبت شود |
| RPID | ثبت شود |
| PPI | ثبت شود |
| Yealink Display | ثبت شود |
اگر Display دقیقاً با یکی از Headerها تطبیق دارد، تقریباً مشخص است Caller ID Source از کدام مسیر انتخاب شده است.
اگر تمام Headerها شماره اشتباه دارند
در این حالت Yealink مشکل اصلی نیست.
Phone فقط اطلاعاتی را نمایش می‌دهد که PBX یا Provider تحویل داده است.
مسیر بررسی را به عقب ببرید:
Yealink ← PBX ← SBC ← SIP Trunk ← Provider
Capture را در PBX یا SBC نیز بگیرید و ببینید شماره در کدام نقطه تغییر می‌کند.
اگر Provider شماره درست می‌دهد ولی PBX آن را تغییر می‌دهد
قوانین Caller ID Rewrite، Inbound Route، Dialplan، Trunk Settings و Trust Policy را بررسی کنید.
گاهی Provider این مقدار را می‌فرستد:
P-Asserted-Identity: <sip:+989121234567@provider.example>اما PBX به Yealink این را می‌فرستد:
From: <sip:200@pbx.local>در چنین شرایطی اصلاح Caller ID در PBX تمیزتر از ایجاد Workaround روی تمام تلفن‌هاست.
Asterisk PJSIP و Trust Caller ID
اگر از Asterisk با PJSIP استفاده می‌کنید، گزینه trust_id_inbound تعیین می‌کند Asterisk اطلاعات Identity دریافت‌شده از Endpoint یا Trunk، مانند PAI و RPID را بپذیرد یا نه.
نمونه:
[provider]
type=endpoint
trust_id_inbound=yesاین گزینه را فقط برای Endpoint یا Trunkی فعال کنید که واقعاً به آن اعتماد دارید. پذیرش Identity از Source غیرقابل اعتماد می‌تواند امکان جعل Caller ID را ایجاد کند.
ارسال PAI از Asterisk به Yealink
Asterisk برای Endpoint گزینه زیر را نیز دارد:
send_pai=yesو برای Remote-Party-ID:
send_rpid=yesلازم نیست هر دو را کورکورانه فعال کنید. معماری Caller ID را بر اساس Provider و Endpointها یکدست کنید.
نمونه Endpoint برای ارسال Caller ID به Yealink
[yealink-201]
type=endpoint
callerid=Office 201 <201>
send_pai=yes
send_connected_line=yesاین فقط نمونه ساختاری است. Configuration واقعی باید با Dialplan، نسخه Asterisk و معماری PBX شما تطبیق داده شود.
Privacy می‌تواند شماره درست را به Anonymous تبدیل کند
اگر Yealink به‌جای شماره، Anonymous نمایش می‌دهد، Header زیر را بررسی کنید:
Privacy: idدر تنظیمات فعلی Yealink، پردازش Privacy به‌صورت پیش‌فرض فعال است.
پارامتر:
account.X.cid_source_privacy = 1اگر Privacy: id داخل INVITE باشد، Phone می‌تواند Caller ID را Anonymous نمایش دهد.
آیا account.X.cid_source_privacy را خاموش کنیم؟
Yealink در FAQ فنی خود برای عیب‌یابی بعضی سناریوها امکان غیرفعال‌کردن آن را ذکر می‌کند:
account.1.cid_source_privacy = 0اما این را به‌عنوان تنظیم عمومی Production توصیه نکنید. اگر تماس‌گیرنده واقعاً Privacy درخواست کرده باشد، نادیده‌گرفتن آن می‌تواند برخلاف Policy اپراتور یا سازمان باشد.
اول مشخص کنید چرا PBX یا Provider این Header را اضافه کرده است.
P-Preferred-Identity یا PPI
Firmwareهای فعلی Yealink امکان پردازش P-Preferred-Identity را نیز دارند.
پارامتر:
account.X.cid_source_ppiدر مستند فعلی مقدار پیش‌فرض آن غیرفعال است.
اگر Provider شما PPI استفاده نمی‌کند، نیازی به فعال‌سازی آن فقط برای آزمایش تصادفی نیست.
Country Format چگونه Caller ID را گیج‌کننده می‌کند؟
Providerها و PBXها ممکن است همان شماره را با فرمت‌های مختلف ارسال کنند.
برای یک موبایل فرضی:
09121234567
9121234567
989121234567
+989121234567از نظر انسان این‌ها می‌توانند یک شماره باشند، اما PBX و Directory Matching ممکن است آن‌ها را به شکل یکسان تفسیر نکنند.
بهترین محل Normalization معمولاً PBX است
اگر یک Provider شماره را با +98 و Provider دیگر با 0 ارسال می‌کند، بهتر است قبل از رساندن تماس به تلفن‌ها یک Policy مشخص برای Normalization داشته باشید.
مثلاً تصمیم بگیرید Caller ID داخلی سازمان همیشه به فرمت E.164 برسد:
+989121234567یا همیشه به قالب داخلی سازمان:
09121234567یک Policy یکسان معمولاً از ایجاد صدها استثنا روی تلفن‌های مختلف جلوگیری می‌کند.
Local Directory می‌تواند نام دیگری را جایگزین Caller ID کند
این نکته بسیار مهم است. Yealink در مستند Line Identification اعلام می‌کند اگر Caller یا Callee داخل Local Directory موجود باشد، نام مخاطب ذخیره‌شده روی تلفن با اولویت نمایش داده می‌شود و همان نام در Call Log نیز ذخیره می‌شود.
بنابراین این سناریو ممکن است رخ دهد:
| منبع | مقدار |
|---|---|
| PAI | 09121234567 |
| SIP Display Name | Ali |
| Local Directory | Reza – 09121234567 |
| نمایش احتمالی | Reza |
در این حالت PBX Caller ID صحیح را ارسال کرده ولی Contact ذخیره‌شده روی Yealink اشتباه است.
اگر شماره درست است ولی فقط نام اشتباه است
قبل از دست‌زدن به PAI و From، شماره را در این منابع جست‌وجو کنید:
Local Directory،
Remote Phonebook،
LDAP Directory،
و Directoryهای Push شده توسط PBX یا Provisioning.
مخاطب قدیمی یا Duplicate را اصلاح کنید و تماس را دوباره تست کنید.
فرمت متفاوت شماره می‌تواند Contact Matching را خراب کند
اگر مخاطب با این فرمت ذخیره شده باشد:
09121234567ولی Provider این را تحویل دهد:
+989121234567رفتار تطبیق می‌تواند با Directory Source و Firmware متفاوت باشد. بهترین روش این است که فرمت تماس‌های ورودی و دفترچه تلفن را استاندارد کنید.
شماره قبل از Answer درست است ولی بعد از Answer تغییر می‌کند
این موضوع معمولاً دیگر CLIP ساده نیست و باید Connected Line Identification Presentation یا COLP را بررسی کنید.
Yealink می‌تواند Connected Party را از منابعی مانند PAI، RPID، Dialed Digits، Contact یا مکانیزم RFC 4916 دریافت کند.
پارامتر مرتبط:
account.X.cp_sourceمقادیر Connected Party Source در Yealink
| مقدار | منبع Connected Identity |
|---|---|
| 0 | PAI / RPID |
| 1 | Dialed Digits |
| 2 | RFC 4916 |
| 3 | Contact |
چرا بعد از Transfer Caller ID عوض می‌شود؟
فرض کنید با داخلی 201 تماس گرفته‌اید ولی 201 تماس را به 202 منتقل می‌کند.
بعد از Transfer، Party واقعاً متصل‌شده دیگر 201 نیست؛ 202 است.
PBX می‌تواند Connected Identity جدید را برای Phone ارسال کند و تلفن نیز نمایش را Update کند.
پس تغییر Caller ID بعد از Transfer همیشه Bug نیست.
RFC 4916 و UPDATE
Yealink از RFC 4916 برای Connected Identity پشتیبانی می‌کند. در این مدل، Endpoint می‌تواند تغییر Identity را داخل یک UPDATE در همان SIP Dialog اعلام کند.
نمونه مفهومی:
UPDATE sip:201@phone.local SIP/2.0
From: "Extension 202" <sip:202@pbx.local>اگر شماره فقط بعد از Answer یا Transfer تغییر می‌کند، Packet Capture را تا بعد از Answer ادامه دهید و فقط INVITE اولیه را بررسی نکنید.
Diversion و Forward چه اثری دارند؟
در تماس Forward شده چند Identity ممکن است هم‌زمان وجود داشته باشد:
تماس‌گیرنده اصلی،
داخلی‌ای که تماس به آن رسیده،
داخلی‌ای که Forward کرده،
و مقصد نهایی.
PBX ممکن است برای حفظ اطلاعات Forward از Headerهایی مانند Diversion یا History-Info استفاده کند.
اگر فقط تماس‌های Forward شده Caller ID اشتباه دارند، Capture یک تماس مستقیم و یک تماس Forward شده را کنار هم مقایسه کنید.
Provider Behavior را با یک تماس مستقیم مقایسه کنید
برای اینکه مشخص شود Provider مقصر است یا PBX، یک تست Baseline بسازید.
| تست | هدف |
|---|---|
| موبایل → Trunk → Yealink | Caller ID خارجی |
| داخلی → Yealink | Caller ID داخلی |
| Trunk → Forward → Yealink | Diversion |
| تماس → Transfer → Yealink | Connected Identity |
اگر فقط تماس‌های Trunk مشکل دارند، Provider/PBX Boundary مهم‌تر است. اگر حتی داخلی به داخلی اشتباه است، Configuration خود PBX یا Directory را بررسی کنید.
اگر فقط یک Yealink شماره اشتباه نشان می‌دهد
وقتی بقیه تلفن‌های همان PBX Caller ID درست دارند، Provider و Trunk کمتر محتمل می‌شوند.
روی دو Phone این موارد را مقایسه کنید:
| تنظیم | Phone سالم | Phone مشکل‌دار |
|---|---|---|
| Caller ID Source | ثبت شود | ثبت شود |
| Firmware | ثبت شود | ثبت شود |
| Local Directory | بررسی شود | بررسی شود |
| Account | مقایسه شود | مقایسه شود |
| Provisioning | مقایسه شود | مقایسه شود |
اگر همه Yealinkها شماره اشتباه نشان می‌دهند
به احتمال بیشتری مشکل مشترک است.
Caller ID Source از Provisioning،
PBX Caller ID Policy،
SIP Trunk،
Provider،
یا Number Normalization
را بررسی کنید.
Auto Provisioning می‌تواند Caller ID Source را برگرداند
اگر Caller ID Source را در Web UI تغییر می‌دهید و درست می‌شود ولی بعد از Reboot دوباره مشکل برمی‌گردد، فایل Provisioning را بررسی کنید.
ممکن است داخل CFG این مقدار وجود داشته باشد:
account.1.cid_source = 0و هر بار From را دوباره به‌عنوان Source انتخاب کند.
نمونه تنظیم یکدست Caller ID با Provisioning
اگر PBX شما همیشه PAI صحیح ارسال می‌کند و در صورت نبود PAI باید From استفاده شود:
#!version:1.0.0.1
account.1.cid_source = 2اگر چند Account دارید، X را متناسب با Account واقعی تغییر دهید.
وقتی Caller ID در W70/W80/W90 اشتباه است
همین منطق روی سیستم‌های DECT جدید Yealink نیز وجود دارد.
در W70B مسیر Caller ID Source از Account قابل تنظیم است.
در Multi-Cellهای W75/W80/W90، Yealink در مستند فعلی مسیر زیر را معرفی می‌کند:
Handset & Account → Handset Registration → Add Handset / Edit → Caller ID Source
پس مشکل Caller ID در W90 الزاماً از خود Handset نیست؛ Source می‌تواند در DECT Manager/Account Configuration تعریف شده باشد.
Caller ID اشتباه در تماس خروجی را جدا بررسی کنید
اگر روی Yealink شماره شخص مقابل هنگام تماس خروجی اشتباه نمایش داده می‌شود، این مسئله می‌تواند Connected Party Identification باشد، نه Incoming Caller ID.
برای مثال اگر شما 201 را شماره می‌گیرید اما تماس توسط 202 پاسخ داده می‌شود، PBX ممکن است Connected Identity را به 202 تغییر دهد.
در این حالت `account.X.cp_source` و SIP UPDATE/PAI/RPID را بررسی کنید.
اگر طرف مقابل شماره شما را اشتباه می‌بیند
این دیگر Caller ID دریافتی Yealink نیست؛ موضوع Caller ID خروجی شماست.
مسیر عیب‌یابی:
Yealink → PBX → Trunk → Provider → مقصد
From، PAI و Identity ارسال‌شده توسط PBX را در خروجی بررسی کنید.
Provider ممکن است Caller ID دلخواه را قبول نکند و شماره مجاز Trunk را جایگزین کند.
Caller ID Spoofing و Trust را جدی بگیرید
Caller ID فقط موضوع نمایش نیست؛ یک موضوع امنیتی نیز هست.
PAI باید در چارچوب Trust Domain استفاده شود. اگر PBX هر P-Asserted-Identity را از هر Endpoint ناشناسی بپذیرد، امکان جعل Identity ایجاد می‌شود.
بنابراین تنظیم‌هایی مثل:
trust_id_inbound=yesرا فقط روی Trunk یا Endpoint مورد اعتماد فعال کنید.
سناریوی اول: Yealink شماره Trunk را به‌جای تماس‌گیرنده نشان می‌دهد
INVITE را بررسی کنید.
اگر From برابر شماره Trunk ولی PAI برابر شماره تماس‌گیرنده است، Caller ID Source را مطابق ساختار Provider انتخاب کنید.
اگر همه Headerها شماره Trunk را دارند، PBX یا Provider را اصلاح کنید.
سناریوی دوم: Yealink همیشه Anonymous نشان می‌دهد
Privacy: id را بررسی کنید.
Caller ID Source را بررسی کنید.
اگر روی PAI تنظیم شده ولی PBX PAI نمی‌فرستد، ممکن است Identity معتبر در دسترس Phone نباشد.
تغییر Source به PAI-FROM می‌تواند در معماری مناسب Failover به From ایجاد کند.
سناریوی سوم: شماره درست است ولی نام اشتباه است
Local Directory را بررسی کنید.
شماره را داخل Phonebook جست‌وجو کنید.
اگر Contact قدیمی یا Duplicate وجود دارد آن را اصلاح کنید.
این سناریو نیازی به تغییر PAI ندارد اگر خود شماره درست است.
سناریوی چهارم: +98 به‌جای 0 نمایش داده می‌شود
این الزاماً خطا نیست؛ Provider ممکن است شماره را در قالب بین‌المللی ارسال کند.
اگر سازمان فرمت 09 را می‌خواهد، بهتر است Number Normalization روی PBX انجام شود تا تمام تلفن‌ها و Directoryها یک رفتار داشته باشند.
سناریوی پنجم: فقط تماس Forward شده شماره اشتباه دارد
Capture تماس مستقیم و Forward شده را مقایسه کنید.
PAI، From، Diversion، History-Info و Connected Identity را بررسی کنید.
ممکن است PBX شماره Forwarder را به‌جای Original Caller داخل Source انتخاب‌شده قرار دهد.
سناریوی ششم: شماره بعد از Answer تغییر می‌کند
COLP و Connected Identity را بررسی کنید.
پیام‌های بعد از 200 OK، UPDATE و Re-INVITE را ببینید.
اگر Phone طبق RFC 4916 Identity جدید می‌گیرد، تغییر Display می‌تواند رفتار طبیعی باشد.
سناریوی هفتم: فقط یک تلفن مشکل دارد
Caller ID Source، Firmware، Directory و Provisioning را با Phone سالم مقایسه کنید.
اگر هر دو همان SIP INVITE را دریافت می‌کنند ولی فقط یکی نمایش متفاوت دارد، مشکل سمت Phone/Configuration محتمل‌تر است.
سناریوی هشتم: همه تلفن‌ها مشکل دارند
PBX و Provider را بررسی کنید.
یک Capture قبل و بعد از PBX مقایسه کنید.
اگر شماره قبل از PBX درست و بعد از PBX اشتباه است، Dialplan یا Caller ID Policy را اصلاح کنید.
سناریوی نهم: بعد از Reboot دوباره Caller ID خراب می‌شود
Auto Provisioning را بررسی کنید.
Common CFG، MAC CFG یا Device Template ممکن است `cid_source` قدیمی را دوباره Push کند.
سناریوی دهم: Caller ID روی Yealink درست است ولی در Call Log اشتباه ذخیره می‌شود
Local Directory و Contact Matching را بررسی کنید.
Yealink اعلام می‌کند در صورت وجود Contact محلی، نام Local Contact می‌تواند با اولویت نمایش داده و در Call Log نیز ثبت شود.
یک روش سریع برای پیدا کردن مقصر
| مرحله | بررسی | نتیجه |
|---|---|---|
| ۱ | From | Caller ID اولیه |
| ۲ | PAI | Identity تأییدشده شبکه |
| ۳ | RPID/PPI | Sourceهای جایگزین |
| ۴ | Privacy | تشخیص Anonymous واقعی |
| ۵ | Caller ID Source | مشخص‌کردن Header منتخب Yealink |
| ۶ | Local Directory | تشخیص Name Override |
| ۷ | PBX | Normalization و Trust |
| ۸ | Provider | Caller ID ورودی واقعی |
| ۹ | UPDATE/COLP | تغییر Identity بعد از Answer |
| ۱۰ | Provisioning | جلوگیری از بازگشت تنظیمات اشتباه |
چک‌لیست نهایی Caller ID در Yealink
| بررسی | هدف |
|---|---|
| From | مقایسه شماره اولیه |
| P-Asserted-Identity | Identity مورد اعتماد PBX/Provider |
| Remote-Party-ID | بررسی سیستم‌های Legacy |
| P-Preferred-Identity | بررسی Priority جدیدتر |
| Caller ID Source | انتخاب Source صحیح Yealink |
| Privacy | تشخیص Anonymous |
| Country Format | یکسان‌سازی +98، 98 و 0 |
| Local Directory | تشخیص Name Override |
| Forward/Transfer | تشخیص Connected Identity |
| PBX Trust | جلوگیری از Caller ID Spoofing |
| Provider | تأیید Caller ID ورودی |
| Auto Provisioning | جلوگیری از بازگشت cid_source |
پرسش‌های متداول درباره Caller ID در Yealink
چرا Yealink شماره تماس‌گیرنده را اشتباه نشان می‌دهد؟
معمولاً یا PBX/Provider شماره اشتباه داخل SIP Header ارسال می‌کند یا Caller ID Source تلفن روی Header نامناسب قرار گرفته است. From، PAI و RPID را در INVITE مقایسه کنید.
P-Asserted-Identity در Yealink چیست؟
PAI Headerی است که در شبکه SIP مورد اعتماد برای حمل Identity تأییدشده استفاده می‌شود. Yealink می‌تواند Caller ID را از این Header استخراج کند.
چرا شماره درست است ولی نام فرد دیگری نمایش داده می‌شود؟
Local Directory را بررسی کنید. Yealink در صورت تطبیق Caller با مخاطب محلی، نام ذخیره‌شده Contact را با اولویت نمایش می‌دهد.
چرا Yealink به‌جای شماره Anonymous نشان می‌دهد؟
Privacy: id، Caller ID Source و Headerهای SIP را بررسی کنید. اگر Privacy فعال باشد، Phone می‌تواند مطابق درخواست شبکه Identity را مخفی کند.
چرا +98 به‌جای 0 نمایش داده می‌شود؟
Provider یا PBX ممکن است Caller ID را با قالب بین‌المللی ارسال کند. اگر سازمان قالب دیگری نیاز دارد، Number Normalization را بهتر است به‌صورت مرکزی روی PBX انجام دهید.
چرا بعد از Transfer شماره روی Yealink تغییر می‌کند؟
بعد از Transfer طرف واقعاً متصل‌شده ممکن است تغییر کند. PBX می‌تواند Connected Identity جدید را از طریق PAI، RPID یا UPDATE ارسال کند و Yealink Display را به‌روزرسانی کند.
Caller ID Source در Yealink کجاست؟
در بسیاری از تلفن‌های رومیزی از مسیر Account → Advanced → Caller ID Source قابل تنظیم است. در W80/W90 تنظیم مشابه از بخش Handset Registration انجام می‌شود.
آیا بهتر است Caller ID Source را روی PAI بگذاریم؟
نه همیشه. Source صحیح به PBX و Provider شما بستگی دارد. ابتدا PCAP را بررسی کنید و ببینید شماره معتبر در کدام Header قرار دارد. PAI-FROM یا Priority سفارشی در بعضی شبکه‌ها مناسب‌تر است.
چرا فقط یک Yealink Caller ID اشتباه دارد؟
Caller ID Source، Firmware، Local Directory و Provisioning آن Phone را با یک تلفن سالم مقایسه کنید. اگر هر دو INVITE یکسان دریافت می‌کنند، مشکل بیشتر سمت تنظیمات Phone است.
آیا Factory Reset مشکل Caller ID را حل می‌کند؟
معمولاً خیر. Factory Reset نمی‌تواند Caller ID اشتباه Provider یا PBX را اصلاح کند. ابتدا SIP Header، Caller ID Source، Directory و Provisioning را بررسی کنید.
جمع‌بندی
وقتی شماره تماس‌گیرنده روی Yealink اشتباه نمایش داده می‌شود، اول باید مشخص کنید Phone این Identity را از کدام SIP Header گرفته است. From، P-Asserted-Identity، Remote-Party-ID و در بعضی Firmwareها P-Preferred-Identity می‌توانند Source نمایش Caller ID باشند.
یک Packet Capture بگیرید و Headerها را با آنچه روی LCD دیده می‌شود مقایسه کنید. اگر شماره صحیح داخل PAI است ولی تلفن From را می‌خواند، Caller ID Source را مطابق معماری PBX اصلاح کنید. اگر تمام Headerها اشتباه‌اند، مشکل را در PBX، SBC یا Provider پیدا کنید.
اگر شماره درست ولی نام اشتباه است، Local Directory را بررسی کنید؛ Yealink می‌تواند نام مخاطب محلی را با اولویت نمایش دهد. همچنین فرمت شماره‌های +98، 98، 0 و بدون Prefix را در PBX استاندارد کنید تا Directory Matching و Call Log رفتار قابل پیش‌بینی داشته باشند.
برای تماس‌هایی که بعد از Answer، Forward یا Transfer شماره‌شان تغییر می‌کند، Connected Line Identification و پیام‌های بعدی SIP را بررسی کنید. در این سناریو تغییر Display ممکن است رفتار درست سیستم باشد، نه خرابی تلفن.
در نهایت Trust را جدی بگیرید. PAI برای شبکه‌های مورد اعتماد طراحی شده و PBX نباید Identity هر Endpoint ناشناسی را بدون بررسی قبول کند. با این مسیر معمولاً می‌توان Caller ID اشتباه را بدون Factory Reset و بدون دستکاری تصادفی Firmware برطرف کرد.
SIP Header و تنظیمات مرکز تلفن را دقیق بررسی کنید
اگر شماره تماس‌گیرنده اشتباه، Anonymous یا با فرمت نادرست روی تلفن‌های Yealink نمایش داده می‌شود، می‌توانید درخواست بررسی کانفیگ ثبت کنید تا Caller ID Source، SIP Header، PBX و تنظیمات مرتبط با سرویس VoIP بررسی شوند.
تماس با پشتیبانی ایرانیکاسرور
دیدگاه‌ها (۰)