مانیتورینگ کیفیت تماس VoIP با RTCP؛ بررسی Jitter، Packet Loss و MOS

اگر می‌خواهید کیفیت واقعی تماس VoIP را اندازه بگیرید، فقط Ping و حتی RTP Packet Count کافی نیست. RTCP کنار RTP کار می‌کند و از دید گیرنده اطلاعاتی مثل Packet Loss، Jitter، Round-Trip Time و وضعیت دریافت Media را گزارش می‌دهد. در نسخه گسترده‌تر یعنی RTCP XR، حتی می‌توان Burst Loss، Jitter Buffer Discard، Delay و شاخص‌های کیفیتی مانند R-Factor و MOS را هم گزارش کرد.

این مقاله روی RTCP VoIP Monitoring تمرکز دارد؛ یعنی چگونه از RTCP برای تشخیص واقعی کیفیت تماس استفاده کنیم، تفاوت Jitter و Packet Loss شبکه را با مشکل Jitter Buffer بفهمیم، MOS را درست تفسیر کنیم و Thresholdهایی بسازیم که به‌جای تولید هزاران هشدار بی‌ارزش، مشکل واقعی کاربر را نشان دهند.

نکته مهم این است که RTCP «صدای تماس» نیست؛ RTP Media را حمل می‌کند و RTCP درباره همان جریان Media گزارش می‌دهد. بنابراین می‌توانید بدون گوش‌دادن به محتوای مکالمه، بخش بزرگی از کیفیت انتقال را اندازه‌گیری کنید.

RTCP چیست و چه تفاوتی با RTP دارد؟

RTP بسته‌های صوت یا ویدئو را جابه‌جا می‌کند. RTCP یا RTP Control Protocol برای گزارش وضعیت Session به‌کار می‌رود. طبق RFC 3550، Sender Report و Receiver Report می‌توانند اطلاعاتی مثل تعداد Packet دریافت‌شده، Packet Loss، Sequence Number و Interarrival Jitter را منتقل کنند.

RTP:
Audio packets
A =========================> B

RTCP:
Quality feedback
A <-----------------------> B

پس اگر A به B صدا می‌فرستد، کیفیت آن جهت را بهتر است از دید گیرنده B بررسی کنید؛ چون گیرنده می‌داند چه Packetهایی دیر رسیده‌اند، کدام Sequence Numberها گم شده‌اند و Jitter دریافتی چقدر بوده است.

Receiver Report چه چیزهایی به ما می‌دهد؟

RTCP Receiver Report در RFC 3550 چند Metric پایه دارد که برای مانیتورینگ بسیار مهم‌اند:

RFC 3550 یک نکته مهم دارد: مقدار Jitter در یک Receiver Report فقط یک Snapshot است و برای مقایسه چند Report در طول زمان مفیدتر است. بنابراین Alert روی یک مقدار تنها، طراحی خوبی نیست.

Jitter دقیقاً چیست؟

Jitter در VoIP یعنی فاصله زمانی رسیدن Packetها یکنواخت نیست. ممکن است Codec هر ۲۰ میلی‌ثانیه یک Packet بسازد، اما Packetها در مقصد با فاصله‌های ۱۸، ۲۳، ۱۹ و ۳۲ میلی‌ثانیه برسند.

Ideal:
20ms  20ms  20ms  20ms  20ms

Real network:
18ms  23ms  19ms  32ms  11ms

Jitter Buffer بخشی از این نوسان را جذب می‌کند، اما Buffer بزرگ‌تر Delay را هم بیشتر می‌کند. به همین دلیل «Jitter بالا» و «صدای بد» دقیقاً یک چیز نیستند؛ ممکن است Adaptive Jitter Buffer بخشی از مشکل را پنهان کند.

Packet Loss؛ فقط درصد کل را نگاه نکنید

دو تماس ممکن است هر دو ۱٪ Packet Loss داشته باشند اما کیفیت شنیداری بسیار متفاوتی ایجاد کنند.

حالت اول:

Loss pattern:
X . . . . . . . X . . . . . . X

Mostly isolated loss

حالت دوم:

Loss pattern:
. . . X X X X . . . . . . . .

Burst loss

در حالت دوم چند Packet پشت سر هم از دست می‌روند و احتمال قطع‌شدن یک واژه یا بخش قابل‌شنیدن مکالمه بیشتر است. RFC 3611 برای همین موضوع Burst و Gap Metrics را در RTCP XR تعریف می‌کند.

RTCP XR چه چیزی به RTCP معمولی اضافه می‌کند؟

RFC 3611، RTCP Extended Reports یا RTCP XR را تعریف می‌کند. برای VoIP، مهم‌ترین بخش آن VoIP Metrics Report Block است.

یکی از مفیدترین تفاوت‌ها این است که RFC 3611، Network Loss و Jitter Buffer Discard را جدا می‌کند. هر دو می‌توانند صدای خراب بسازند، اما علتشان یکی نیست.

Packet Loss با Jitter Buffer Discard چه فرقی دارد؟

فرض کنید Packet به سیستم رسیده، اما آن‌قدر دیر رسیده که Jitter Buffer دیگر نمی‌تواند آن را پخش کند. از دید Network، Packet «گم نشده»؛ اما از دید کاربر آن بخش صدا از دست رفته است.

Network loss:
Packet never arrives

Jitter buffer discard:
Packet arrives
        |
        v
Too late for playout
        |
        v
Discarded

اگر فقط Network Loss را مانیتور کنید، ممکن است تماس با ۰٪ Loss را سالم تصور کنید در حالی که Jitter Buffer تعداد زیادی Packet را دور انداخته است.

MOS چیست و چرا نباید آن را «حقیقت مطلق» بدانیم؟

MOS یا Mean Opinion Score معمولاً روی مقیاس ۱ تا ۵ نمایش داده می‌شود. در سیستم‌های مانیتورینگ مدرن این عدد اغلب برآوردشده است؛ یعنی از ترکیبی از Loss، Jitter، Delay، Codec و مدل کیفیت ساخته می‌شود.

RFC 3611 در VoIP Metrics Report Block امکان گزارش MOS و R-Factor را فراهم می‌کند و توضیح می‌دهد Quality Metric باید اثر Codec، Loss، Discard، Burstiness و Delay را در نظر بگیرد.

پس دو تماس با Packet Loss یکسان ممکن است MOS یکسانی نداشته باشند؛ Codec، PLC، Jitter Buffer و Delay هم اثر دارند.

RTCP در Asterisk؛ چه Metricهایی در دسترس است؟

Asterisk در تابع CHANNEL() امکان خواندن آمار RTCP را فراهم می‌کند. طبق مستند فعلی، می‌توانید Summary یا Metricهای Jitter، Loss و RTT را بخوانید.

نمونه:

same => n,NoOp(RTCP all: ${{CHANNEL(rtcp,all)}})
same => n,NoOp(RTCP jitter: ${{CHANNEL(rtcp,all_jitter)}})
same => n,NoOp(RTCP loss: ${{CHANNEL(rtcp,all_loss)}})
same => n,NoOp(RTCP RTT: ${{CHANNEL(rtcp,all_rtt)}})

خروجی Summary می‌تواند اطلاعاتی مثل SSRC، Lost Packet Count، RX/TX Jitter، RX/TX Packet Count، Remote Lost Packet Count، RTT و Media Experience Score را شامل شود.

اگر Application شما با ARI کار می‌کند، Asterisk نیز Endpoint زیر را برای آمار RTP Channel ارائه می‌دهد:

GET /channels/{{channelId}}/rtp_statistics

در معماری مانیتورینگ، بهتر است Metricها را به Collector یا Time-Series Database ارسال کنید؛ چاپ‌کردن دائم آن‌ها در Log برای محیط پرترافیک انتخاب مناسبی نیست.

گزارش کیفیت تماس با VQ-RTCPXR

RFC 6035 یک SIP Event Package با Media Type زیر تعریف می‌کند:

application/vq-rtcpxr

Endpoint یا Gateway می‌تواند Quality Report شامل Call-ID، Local/Remote Address، Packet Loss، Jitter Buffer، Delay و MOS را برای Collector ارسال کند.

این روش برای محیط‌های Enterprise بسیار کاربردی است چون Metricهای کیفیت را با خود Call-ID ارتباط می‌دهد.

HOMER 11 می‌تواند VQ-RTCPXR را دریافت کند

در HOMER 11 گیرنده VQ-RTCPXR به‌صورت پیش‌فرض غیرفعال است و با تنظیم ingest.vqrtcp.enable فعال می‌شود. گزارش‌ها در جدول vqrtcpxr_stats ذخیره و بر اساس Call-ID با Transaction مرتبط می‌شوند.

نمونه Configuration بر اساس مستند فعلی HOMER:

"ingest": {{
  "vqrtcp": {{
    "enable": true,
    "bind_ip": "0.0.0.0",
    "sip_port": 5063,
    "transports": ["udp", "tcp"],
    "methods": ["PUBLISH", "MESSAGE"],
    "reply_200": true,
    "async_queue_depth": 1024,
    "node_id": "homer"
  }}
}}

اگر تجهیز شما RFC 6035 را پشتیبانی کند، می‌توانید Quality Report را مستقیماً به Collector بفرستید و کنار SIP Call Flow همان تماس مشاهده کنید.

Threshold طراحی کنیم؛ اما نه با یک عدد جادویی

برای Jitter، Loss و MOS یک Threshold جهانی که برای همه Codecها، Endpointها و شبکه‌ها درست باشد وجود ندارد. Codec، Packetization، PLC، FEC، Jitter Buffer و نوع دسترسی روی کیفیت نهایی اثر دارند.

با این حال برای شروع می‌توان از مرزهای محافظه‌کارانه استفاده کرد و بعد آن‌ها را با Baseline شبکه خودتان تنظیم کرد. Cisco برای Voice باکیفیت به‌طور تاریخی Jitter کمتر از ۳۰ ms و Packet Loss کمتر از ۱٪ را توصیه کرده است. Twilio نیز در Voice SDK برای سه Sample از پنج Sample، Jitter بالاتر از ۳۰ ms، Packet Loss بالاتر از ۱٪، RTT بالاتر از ۴۰۰ ms و MOS کمتر از ۳٫۵ را Warning می‌داند.

این جدول Standard رسمی واحد نیست. یک نقطه شروع عملی برای Alerting است. برای مثال Twilio در بعضی SIP/Carrier Flowها Threshold متفاوتی از SDK دارد؛ بنابراین Threshold نهایی باید با Codec، Endpoint و تجربه واقعی کاربران شما Calibrate شود.

روی یک Sample هشدار ندهید

Network Spike کوتاه همیشه به معنی تماس بد نیست. Alert بهتر باید Persistence داشته باشد.

مثلاً:

Warning:
jitter > 30 ms
for 3 of last 5 samples

Critical:
packet_loss > 3%
AND mos < 3.5
for 3 consecutive samples

Twilio نیز برای Voice SDK بسیاری از Warningها را بر اساس «۳ Sample از ۵ Sample» ایجاد می‌کند؛ این روش از Alert شدن روی Spike تک‌لحظه‌ای جلوگیری می‌کند.

Average، Max و Percentile را کنار هم نگه دارید

اگر فقط Average Jitter را ذخیره کنید، یک Burst کوتاه اما بسیار بد ممکن است در میان چند دقیقه تماس پنهان شود.

برای هر Leg بهتر است حداقل این‌ها را داشته باشید:

برای Dashboard سازمانی، P95 یا P99 روی مجموعه تماس‌ها هم مفید است؛ چون Average کل روز ممکن است تجربه بد تعداد محدودی تماس را پنهان کند.

هر جهت تماس را جدا مانیتور کنید

کیفیت A → B و B → A لزوماً یکسان نیست. Routing، Wi-Fi، ISP، NAT و Queue می‌توانند Asymmetric باشند.

Direction A -> B:
loss = 0.2%
jitter = 8 ms
MOS = 4.3

Direction B -> A:
loss = 4.1%
jitter = 38 ms
MOS = 3.1

اگر فقط یک MOS نهایی برای کل تماس ذخیره کنید، Root Cause یک‌طرفه را از دست می‌دهید.

RTT را با One-Way Delay اشتباه نگیرید

RTCP معمولاً می‌تواند Round-Trip Time را تخمین بزند. اما نصف‌کردن RTT همیشه One-Way Delay واقعی را نمی‌دهد؛ مسیر رفت و برگشت می‌تواند متفاوت باشد.

اگر SLA شما بر One-Way Delay حساس است، Measurement مناسب‌تری در هر دو Endpoint لازم دارید. RTCP RTT برای Trend و مقایسه بسیار مفید است، اما به‌تنهایی جای Measurement یک‌طرفه دقیق را نمی‌گیرد.

چطور Root Cause را از روی Metricها حدس نزنیم و تشخیص دهیم؟

RTCP همیشه موجود یا کامل نیست

RTCP یک گزارش Best-Effort است. RFC 6035 هم تأکید می‌کند RTCP Reportها محدودیت دارند و نباید تصور کرد نبود Report یعنی کیفیت خوب بوده است.

دلایل رایج نبودن Metric:

بنابراین Dashboard باید وضعیت «Metric unavailable» را از «Metric = 0» جدا کند.

یک طراحی عملی برای مانیتورینگ کیفیت VoIP

Phones / SBC / PBX
       |
       | RTP + RTCP / RTCP XR
       v
Metric Collector
       |
       +--> Call-ID correlation
       |
       +--> Time-series metrics
       |
       +--> HOMER / VQ-RTCPXR
       |
       +--> Alert engine
       |
       v
Dashboard / NOC

کلید موفقیت این است که Metric را با Call-ID، Direction، Endpoint، Site، ISP، Codec و Timestamp ذخیره کنید. بدون این Dimensionها فقط می‌دانید «کیفیت بد بوده»، اما نمی‌دانید کجا.

Dashboard خوب چه نمودارهایی دارد؟

برای NOC، «درصد تماس‌های بد» معمولاً از Average کل تماس‌ها مفیدتر است. اگر ۹۵٪ تماس‌ها عالی و ۵٪ واقعاً خراب باشند، Average ممکن است ظاهراً سالم دیده شود.

Privacy و Retention

RTCP نسبت به Audio Payload حساسیت کمتری دارد، اما همچنان ممکن است IP، SSRC، Call-ID، Endpoint Identity و Metadata تماس را در سیستم مانیتورینگ نگه دارید.

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

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

RTCP اطلاعات کنترلی و آماری درباره RTP Session می‌دهد؛ از جمله Packet Loss، Interarrival Jitter و اطلاعات لازم برای محاسبه RTT.

RTCP XR چه تفاوتی با RTCP دارد؟

RTCP XR گزارش‌های گسترده‌تری مثل Burst Loss، Discard Rate، Jitter Buffer Delay، R-Factor و MOS را اضافه می‌کند و برای VoIP Monitoring دقیق‌تر مناسب است.

Jitter بالای ۳۰ میلی‌ثانیه یعنی تماس حتماً بد است؟

نه حتماً. ۳۰ ms یک Threshold رایج برای هشدار است، اما Jitter Buffer، Codec و Duration مشکل روی تجربه واقعی اثر دارند. Trend و چند Sample متوالی را بررسی کنید.

Packet Loss چند درصد قابل‌قبول است؟

برای Voice باکیفیت بهتر است Loss زیر ۱٪ بماند، اما Codec و PLC می‌توانند تحمل را تغییر دهند. Alert باید با Baseline سیستم واقعی تنظیم شود.

MOS خوب برای VoIP چقدر است؟

در بسیاری از سیستم‌های عملیاتی MOS بالاتر از ۴ خوب تلقی می‌شود و کمتر از ۳٫۵ ارزش بررسی دارد؛ با این حال روش محاسبه MOS و Codec باید مشخص باشد.

آیا Asterisk می‌تواند RTCP Statistics بدهد؟

بله. CHANNEL(rtcp,…) Metricهایی مثل Jitter، Loss و RTT را ارائه می‌کند و ARI نیز Endpoint مخصوص RTP Statistics دارد.

چرا تماس با ۰٪ Network Loss باز هم صدای بد دارد؟

ممکن است Packetها به شبکه مقصد رسیده باشند اما به‌دلیل Jitter زیاد، Jitter Buffer آن‌ها را دیر دریافت و Discard کرده باشد؛ Delay، Codec و Echo هم می‌توانند عامل باشند.

برای Alert روی یک Spike هشدار بدهیم؟

معمولاً بهتر است نه. Alert بر اساس چند Sample متوالی یا الگویی مثل ۳ Sample از ۵ Sample، False Alarm را کمتر می‌کند.