شنیدنِ بوق یا پیامِ «در انتظار بمانید» لزوماً شاهدِ پاسخِ طرفِ مقابل نیست. در SIP ممکن است رسانه پیش از پذیرشِ درخواستِ برقراریِ جلسه ردوبدل شود؛ این وضعیت Early Media نام دارد. برایِ گزارشِ تماس، بوقِ محلی، رسیدنِ بستهٔ رسانه و پاسخِ نهاییِ درخواست را جدا ثبت کنید. این صفحه هیچ تماسِ واقعی برقرار نمی‌کند.
شاهدها را جدا رویِ خطِ زمان بگذاریم
در دفترِ آموزشیِ ما، پاسخِ۱۸۰، تولیدِ بوقِ محلی، رسیدنِ بستهٔ RTP و۲۰۰ِ مرتبط با INVITE را رویدادهایِ جدا ثبت می‌کنیم. فایل فقط یک مسیرِ ساده‌شده را نشان می‌دهد؛ درگاه‌ها و شاخه‌هایِ هم‌زمانِ واقعی می‌توانند دفترِ پیچیده‌تری لازم داشته باشند. از رویِ یک تصویرِ ناقص، دربارهٔ تمامِ سامانه حکم ندهید.
مرجعِ RFC3960 توضیح می‌دهد سیاستِ تولیدِ بوقِ محلی به وضعیتِ رسانه هم وابسته است. صرفِ دیدنِ پیامِ سیگنالینگ، رسیدنِ صوت را تضمین نمی‌کند. این توضیح را دستورِ تغییرِ سراسریِ تنظیمِ بوق یا رفتارِ قطعیِ همهٔ تلفن‌ها معرفی نمی‌کنیم؛ نسخه و مسیرِ هر سامانه باید جدا بررسی شود.
چهار نمونهٔ ساختگی چه می‌گویند؟
نمونهٔ اول فقط۱۸۰ و رویدادِ تولیدِ بوقِ محلی دارد. دومی۱۸۳، رسیدنِ RTP و سپس۲۰۰ برایِ CANCEL و۴۸۷ برایِ INVITE دارد. سومی پس از۱۸۳ و RTP،۲۰۰ِ همان INVITE و ACK دارد. چهارمی۲۰۰ِ تراکنشِ دیگری را کنارِ۱۸۳ نشان می‌دهد. زمان‌ها میلی‌ثانیهٔ ساختگی‌اند؛ دادهٔ مشتری یا تماسِ آزمایش‌شده نیستند.
| نمونه | پذیرشِ INVITE در دفتر دیده شد؟ | چیزی که هنوز معلوم نیست |
|---|---|---|
| بوقِ محلی | خیر، شاهدِ متناظر نداریم | کامل‌بودنِ ثبت و پاسخِ واقعی |
| رسانه و لغو | خیر؛۲۰۰ برایِ CANCEL است | محتوایِ شنیده‌شده و صورتحساب |
| رسانه و۲۰۰ِ INVITE | بله، در۳۰میلی‌ثانیهٔ نمونه | گفت‌وگویِ انسانی و نتیجهٔ تجاری |
| ۲۰۰ِ تراکنشِ دیگر | خیر، تطبیق ندارد | وضعیتِ INVITEِ موردِ نظر |
عددِ۲۰۰ را بدونِ نامِ درخواست نخوانیم
کد برایِ رویدادِ پذیرش، Call-IDِ ساختگیِ demo، شمارهٔ CSeqِ هفت، روشِ INVITE و وضعیتِ۲۰۰ را با هم می‌خواهد.۲۰۰ِ OPTIONS، CANCEL یا CSeqِ دیگر واردِ این نتیجه نمی‌شود. این تطبیق برایِ fixtureِ سادهٔ ماست؛ parser و هم‌بستگیِ کاملِ دیالوگ، tagها، شاخه‌ها و رفتارِ یک B2BUA پیاده نشده‌اند.
آزمون واقعاً کنترل می‌کند فقط نمونهٔ سوم شاهدِ موردِ نظر را دارد. در نمونهٔ دوم با وجودِ پاسخِ۲۰۰، پذیرشِ INVITE ثبت نمی‌شود. این اختلاف علتِ خوبی است که برایِ عیب‌یابی، ستونِ روشِ درخواست را از لاگ حذف نکنیم و هر پاسخِ موفقِ فنی را «تماسِ پاسخ‌داده‌شده» ننامیم.
رسیدنِ RTP، شنیدنِ انسان را ثابت نمی‌کند
بسته ممکن است اعلان، سکوت یا محتوایِ دیگری داشته باشد. در این تمرین payload باز نشده و صوت پخش نشده است. بنابراین human_conversation_proven و billing_start_proven عمداً null می‌مانند؛ unknown را false یا صفرِ آمار نمی‌نامیم. قراردادِ صورتحسابِ ارائه‌دهنده هم از این دفتر کشف نمی‌شود.
نبودِ رویداد در ثبتِ ناقص، نبودِ قطعیِ اتفاق در جهان نیست. در همهٔ نمونه‌ها کامل‌بودنِ capture تأیید نشده است. برایِ بررسیِ واقعی، بازهٔ زمانی، دو سرِ مجاز، شاخه و محلِ ثبت را همراهِ مسئولِ فنی مشخص کنید؛ رمز و اطلاعاتِ خصوصیِ تماس را در گزارشِ عمومی نگذارید.
این تفکیک در گزارشِ مرکز تماس چه کمکی می‌کند؟
تعریفِ «شروع»، «پاسخ»، «ورود به صف» و «گفت‌وگو» را پیش از مقایسهٔ آمار بنویسید. اگر یک سامانه شروعِ رسانه و سامانهٔ دیگر پاسخِ نهایی را می‌شمارد، اختلافِ عددها الزاماً افزایشِ عملکرد نیست. برگهٔ شواهد را برایِ هم‌معناکردنِ گزارش‌ها استفاده کنید، نه برایِ ساختنِ شاخصِ موفقیتِ تازه.
نقشهٔ کلیِ تحویلِ خط را در SIP Trunk و سانترال ببینید. اگر هدفِ شما پاسخ به تلفنِ ورودی است، تعریفِ نتیجهٔ مطلوب و سامانهٔ فعلی را در درخواستِ منشیِ تلفنیِ اپرا مطرح کنید؛ این مثال وجودِ تنظیمِ Early Mediaِ مشخص در محصول را وعده نمی‌دهد.
فایل تمرین و منبع
چهار دفترِ ساختگیِ سیگنال/رسانه را بر اساسِ شاهد بررسی کنید · رویدادهایِ کامل و نتیجهٔ قابلِ استنتاجِ هر چهار حالت
منابع در 2026-11-04 خوانده شدند؛ این تاریخ، تاریخ انتشار منبع نیست. مثال‌ها و فایل‌های این راهنما آموزشی و ساختهٔ تحریریه‌اند.