مانیتورینگ VoIP با HOMER 11؛ جست‌وجو و تحلیل جریان تماس SIP

HOMER یکی از کاربردی‌ترین ابزارهای متن‌باز برای دیدن چیزی است که واقعاً در شبکه VoIP اتفاق افتاده است. به‌جای اینکه فقط Log یک Asterisk یا SBC را بخوانید، HOMER پیام‌های SIP را از چند نقطه جمع می‌کند، آن‌ها را با HEP ذخیره می‌کند و بعد اجازه می‌دهد یک تماس را با Call-ID، شماره مبدا و مقصد، Response Code، IP، User-Agent و زمان جست‌وجو کنید و کل Call Flow را کنار هم ببینید.

این ابزار برای زمانی ارزش واقعی خود را نشان می‌دهد که کاربر می‌گوید «تماس ساعت ۱۰:۲۳ قطع شد» یا Provider می‌گوید «ما 200 OK فرستادیم». اگر Capture درست طراحی شده باشد، دیگر لازم نیست بین Log چند سرور حدس بزنید؛ INVITE، 100، 180/183، 200، ACK، re-INVITE و BYE را با زمان و مسیر واقعی آن‌ها بررسی می‌کنید.

در بررسی منابع تا ۲۰ اکتبر ۲۰۲۶، شاخه فعال پروژه HOMER نسخه 11.x است و Releaseهای 11.0.x منتشر می‌شوند. HOMER 11 معماری جدیدی مبتنی بر Go، DuckDB/Arrow/Parquet و DuckLake دارد و همچنان با Capture Agentهای HEPv3 سازگار است.

HOMER چیست و چه مشکلی را حل می‌کند؟

HOMER یک پلتفرم Open-Source برای Telecom Observability و SIP/VoIP/RTC Capture است. در HOMER 11 بخش‌های Ingest، Storage، Node و Coordinator می‌توانند در یک برنامه All-in-One یا به‌صورت ماژول‌های جدا اجرا شوند.

برخلاف Packet Capture موقت با tcpdump، HOMER برای نگهداری و جست‌وجوی مداوم طراحی شده است. به همین دلیل برای NOC، تیم VoIP، Provider، Call Center و محیط‌هایی که چند Asterisk، Kamailio، OpenSIPS، FreeSWITCH یا SBC دارند مفید است.

HEP چیست؟

HEP مخفف Homer Encapsulation Protocol است. Capture Agent پیام SIP یا داده‌های مرتبط را همراه Metadata لازم داخل HEP قرار می‌دهد و به Collector می‌فرستد.

معماری ساده:

Asterisk / SBC / Proxy
        |
        | SIP messages
        v
Capture Agent
        |
        | HEPv3
        v
HOMER Ingest
        |
        v
DuckLake / Parquet
        |
        v
Search + Call Flow

مزیت HEP این است که Capture Source می‌تواند از HOMER جدا باشد. مثلاً سه شعبه، دو SBC و چند Asterisk همگی Capture خود را به یک HOMER مرکزی ارسال می‌کنند و هر Agent با Node ID/Name قابل تشخیص است.

چه Agentهایی می‌توانند SIP را برای HOMER بفرستند؟

پروژه HOMER سه مدل اصلی را معرفی می‌کند:

Heplify فعلی می‌تواند SIP، RTCP مرتبط، DNS، Diameter و Log را به HOMER بفرستد و روی Linux، macOS و Windows اجرا شود. برای محیط VoIP معمول، شروع با Capture فقط SIP ساده‌تر و کم‌حجم‌تر است.

یک نمونه Heplify برای Capture فقط SIP

این نمونه روی همه Interfaceها SIP را در Port Range مشخص می‌گیرد و به HOMER می‌فرستد:

./heplify \
  -i any \
  -m SIP \
  -pr 5060-5090 \
  -hs 10.20.0.50:9060 \
  -hi 2001 \
  -hn pbx-a

در این مثال:

Portها و Interface را بر اساس شبکه واقعی خودتان تنظیم کنید؛ اگر SIP روی Port غیرمعمول است، Range پیش‌فرض را کورکورانه استفاده نکنید.

اگر HEP از شبکه عمومی عبور می‌کند

Heplify از Transportهای مختلف از جمله TLS پشتیبانی می‌کند. اگر HEP بین Siteها یا از اینترنت عبور می‌کند، HEP خام UDP انتخاب مناسبی برای داده حساس SIP نیست. TLS را روی Agent و Listener سمت HOMER تنظیم کنید و Certificate Verification را بی‌دلیل غیرفعال نکنید.

./heplify \
  -i any \
  -m SIP \
  -hs homer.example.com:9060 \
  -nt tls \
  -hi 2001 \
  -hn pbx-a

این دستور فقط زمانی درست است که Listener TLS متناظر در سمت HOMER برای همان Port فعال شده باشد.

Passive Capture یا Native HEP؟

اگر SIP شما UDP یا TCP معمولی است، Heplify می‌تواند Packetها را روی Interface ببیند. اما برای SIP/TLS یک Sniffer بیرون از Application فقط ترافیک رمزنگاری‌شده را می‌بیند.

در چنین محیطی Native HEP داخل SIP Stack می‌تواند انتخاب بهتری باشد، چون پیام در نقطه‌ای Capture می‌شود که Application آن را پردازش کرده است. برای مثال در Asterisk می‌توان از HEP/PJSIP Integration استفاده کرد؛ در Kamailio و OpenSIPS نیز ماژول‌های Native Capture وجود دارند.

HOMER 11 داده‌ها را کجا ذخیره می‌کند؟

HOMER 11 نسبت به نسل‌های قدیمی معماری Storage متفاوتی دارد. پروژه فعلی از DuckDB، Apache Arrow/IPC، Parquet و DuckLake استفاده می‌کند و Local Storage یا Object Storage را پشتیبانی می‌کند.

در Wizard رسمی، مسیرهای پیش‌فرض نمونه شامل این موارد هستند:

Catalog:
/data/homer/homer_catalog.sqlite

Parquet data:
/data/homer/parquet

همین معماری باعث می‌شود برای Captureهای بزرگ بتوانید Retention و Tiered Storage را جدا طراحی کنید.

Call-ID Search؛ مهم‌ترین Workflow در HOMER

وقتی کاربر یک تماس خراب گزارش می‌دهد، بهترین Identifier معمولاً SIP Call-ID است. HOMER 11 در Search Mapping، call_id را به Session ID مربوط می‌کند و علاوه بر آن می‌توانید بر اساس Caller، Callee، Method، Response Code، Source/Destination IP، Port و User-Agent جست‌وجو کنید.

مثلاً از CLI جدید HOMER:

homer search \
  --host homer.example.com:8080 \
  --user admin \
  --pass 'YOUR_PASSWORD' \
  --call-id 'abc-def-123@example.com' \
  --from 2h \
  --format callflow

Port Coordinator را با Configuration واقعی خودتان جایگزین کنید.

برای جست‌وجوی INVITEهای یک ساعت اخیر:

homer search \
  --host homer.example.com:8080 \
  --user admin \
  --pass 'YOUR_PASSWORD' \
  --method INVITE \
  --from 1h

چه فیلترهایی برای عیب‌یابی واقعاً مفیدند؟

چرا یک Call-ID گاهی فقط نصف تماس را نشان می‌دهد؟

در Proxyهای شفاف، همان Call-ID ممکن است در مسیر باقی بماند. اما Asterisk و خیلی از B2BUAها می‌توانند برای Leg دیگر Dialog جدا و Call-ID دیگری بسازند.

بنابراین این وضعیت لزوماً به معنی «HOMER Packet را از دست داده» نیست:

Caller
  |
  | Call-ID: A123
  v
Asterisk / B2BUA
  |
  | Call-ID: B987
  v
Provider

HOMER 11 یک Lua Correlation Engine دارد که می‌تواند Dialogهای مرتبط، B2B Legها و Session IDهای دیگر را به Transaction View اضافه کند. همچنین می‌توان Headerهای Correlation مثل X-Call-ID را در Ingest تعریف کرد.

برای محیط B2BUA بزرگ، از ابتدا یک Correlation Header طراحی کنید؛ اینکه بعداً فقط بر اساس شماره و Timestamp دو Leg را حدس بزنید، در ترافیک بالا قابل‌اعتماد نیست.

Capture از چند Node چه مزیتی دارد؟

فرض کنید تماس از Provider به Kamailio و بعد Asterisk می‌رود. اگر فقط کنار Asterisk Capture داشته باشید، نمی‌دانید Provider واقعاً چه فرستاده است.

Provider
   |
   | Capture Node 1
   v
Kamailio / SBC
   |
   | Capture Node 2
   v
Asterisk
   |
   | Capture Node 3
   v
Endpoint

در HOMER می‌توانید Node/Capture ID را ببینید و مشخص کنید مثلاً Header روی Edge وجود داشته ولی قبل از رسیدن به Asterisk Rewrite شده است.

Privacy؛ HOMER می‌تواند اطلاعات حساس ذخیره کند

این بخش را نباید به بعد از نصب موکول کنید. SIP Payload می‌تواند شماره تلفن، Username، IP، Contact، Caller ID، P-Asserted-Identity، User-Agent، SDP و Headerهای مرتبط با Authentication را در خود داشته باشد. اگر SIP MESSAGE استفاده می‌کنید، حتی Body پیام هم ممکن است Capture شود.

بنابراین HOMER را مثل یک Log Server معمولی کم‌اهمیت نبینید.

Capture کمتر یعنی هم Privacy بهتر، هم Storage کمتر

اگر برای Troubleshooting به OPTIONS و NOTIFY نیازی ندارید، Heplify می‌تواند Methodهای مشخص را Drop کند:

./heplify \
  -hs 10.20.0.50:9060 \
  -m SIP \
  -dim OPTIONS,NOTIFY

قبل از حذف هر Method مطمئن شوید تیم شما برای مانیتورینگ Availability یا Troubleshooting به آن نیاز ندارد.

برای سناریوهای پیشرفته‌تر، Heplify از Lua Script برای Filter/Modify کردن Packetها نیز پشتیبانی می‌کند؛ اما Redaction باید دقیق طراحی و تست شود تا Header لازم برای Correlation را از بین نبرد.

آیا RTP Audio را هم Capture کنیم؟

برای بیشتر عیب‌یابی‌های SIP، پاسخ منفی است. Capture کامل RTP حجم Storage و ریسک Privacy را شدیداً بالا می‌برد.

برای شروع، SIP و در صورت نیاز RTCP/QoS کافی است. HOMER 11 قابلیت VQRTCP برای جمع‌آوری گزارش‌های کیفیت تماس و همچنین SIPREC Signaling را دارد، اما این قابلیت‌ها باید آگاهانه فعال شوند.

Storage Sizing؛ برای HOMER چقدر فضا لازم داریم؟

یک عدد ثابت برای همه شبکه‌ها وجود ندارد. Storage به این عوامل وابسته است:

بهترین روش، Benchmark روی ترافیک واقعی خودتان است.

روش اندازه‌گیری واقعی

قبل از شروع پنجره تست:

du -sb /data/homer/parquet
df -h /data/homer

۲۴ ساعت ترافیک نماینده شبکه را Capture کنید و دوباره اندازه بگیرید:

du -sb /data/homer/parquet
df -h /data/homer

سپس بر اساس رشد واقعی روزانه محاسبه کنید:

required_storage =
    measured_daily_growth
  × retention_days
  × safety_headroom

بهتر است اندازه‌گیری را بعد از اینکه Compaction چند بار اجرا شده تکرار کنید، چون اندازه خام لحظه‌ای می‌تواند با اندازه پایدار Parquet متفاوت باشد.

Retention در HOMER 11

Wizard فعلی HOMER 11 برای DuckLake گزینه Retention دارد و مقدار نمونه/پیش‌فرض آن ۳۰ روز است؛ مقدار صفر یعنی Unlimited. برای سامانه‌ای که SIP واقعی کاربران را ذخیره می‌کند، Unlimited را فقط با دلیل مشخص انتخاب کنید.

نمونه بخش Storage:

"storage": {{
  "enable": true,
  "ducklake": {{
    "catalog_type": "sqlite",
    "catalog_path": "/data/homer/homer_catalog.sqlite",
    "data_path": "/data/homer/parquet",
    "compaction": {{
      "enable": true,
      "check_interval_sec": 1800,
      "retention_days": 30
    }}
  }}
}}

HOMER 11 برای Tableهای مختلف TTL جداگانه و Tiered Storage هم دارد؛ بنابراین می‌توانید مثلاً SIP Callها را بیشتر از Logهای کم‌اهمیت نگه دارید یا داده قدیمی را به Object Storage منتقل کنید.

چه چیزهایی Storage را بی‌دلیل منفجر می‌کنند؟

Heplify قابلیت Deduplication هم دارد؛ اگر معماری شما Duplicate واقعی تولید می‌کند، این گزینه ارزش بررسی دارد.

یک Workflow واقعی برای عیب‌یابی تماس

کاربر گزارش می‌دهد: «تماس ۰۹:۴۱ به شماره مشخص وصل نشد.»

Workflow پیشنهادی:

مثلاً:

PBX -> SBC
INVITE

SBC -> Provider
INVITE

Provider -> SBC
100 Trying

Provider -> SBC
488 Not Acceptable Here

SBC -> PBX
488 Not Acceptable Here

با این Capture می‌توانید ثابت کنید 488 از Provider آمده، نه از PBX. این همان ارزشی است که HOMER نسبت به Log جداگانه هر سرور ایجاد می‌کند.

اشتباه‌های رایج در استقرار HOMER

پرسش‌های رایج

HOMER SIP Capture چیست؟

HOMER یک پلتفرم متن‌باز Telecom Observability است که پیام‌های SIP و داده‌های مرتبط را از Capture Agentها دریافت، ذخیره و برای Search و Call Flow Analysis قابل‌استفاده می‌کند.

HEP چه کاری انجام می‌دهد؟

HEP پیام Captureشده و Metadata مربوط به آن را از Agent به HOMER منتقل می‌کند. HEPv3 در Agentهای مختلف VoIP پشتیبانی می‌شود.

آیا می‌توان در HOMER با Call-ID جست‌وجو کرد؟

بله. Call-ID یکی از فیلترهای اصلی HOMER 11 است و می‌توانید Session را در UI یا CLI پیدا و Call Flow آن را مشاهده کنید.

چرا Call-ID فقط یک Leg تماس را نشان می‌دهد؟

اگر Asterisk یا B2BUA برای Leg دوم Call-ID جدید ساخته باشد، باید Correlation بین Sessionها داشته باشید. HOMER 11 برای این کار Lua Correlation و Headerهای Correlation را پشتیبانی می‌کند.

آیا ذخیره SIP در HOMER مشکل Privacy دارد؟

SIP می‌تواند شامل شماره تلفن، IP، Username، Caller ID، Contact، SDP و اطلاعات حساس دیگر باشد. Access Control، TLS برای HEP، Retention محدود و Capture حداقلی باید از ابتدا طراحی شوند.

برای HOMER چقدر Storage نیاز داریم؟

به نرخ تماس، اندازه SIP، تعداد Capture Pointها و Retention بستگی دارد. روش صحیح این است که ۲۴ ساعت ترافیک نماینده را ذخیره و رشد واقعی DuckLake/Parquet را اندازه‌گیری کنید.

آیا باید RTP را هم Capture کنیم؟

برای بیشتر عیب‌یابی‌های Signaling نه. SIP و در صورت نیاز RTCP/QoS معمولاً کافی‌اند. Capture دائمی RTP Payload حجم و ریسک Privacy را بالا می‌برد.

Heplify بهتر است یا Native HEP؟

Heplify برای Packet Capture مستقل و سریع بسیار مناسب است. اگر SIP/TLS دارید یا Capture داخل Application برایتان مهم است، Native HEP روی Asterisk/Kamailio/OpenSIPS می‌تواند مناسب‌تر باشد.