در بعضی مسیرهایِ صوت، هنگامِ بخشِ غیرفعالِ گفتار، ارسالِ بستههایِ صوتی پیوسته نمیماند. DTX دربارهٔ این کاهشِ ارسال است و Comfort Noise به بازسازیِ پسزمینهٔ مناسب در سمتِ دریافت مربوط میشود. فاصلهٔ زمانیِ بستهها را فوراً قطعِ تماس ننامید؛ هم قراردادِ کدک و هم شواهدِ سیگنال و رسانه لازماند.
سه مسئولیت را از هم جدا کنیم
VAD دربارهٔ تشخیصِ بخشِ فعال و غیرفعال است، DTX دربارهٔ زمانِ ارسال در این وضعیت و CNG دربارهٔ تولیدِ پسزمینه. RFC3389 یک قالبِ payload برایِ CN را توضیح میدهد، اما الگوریتمِ کاملِ این سه بخش را به یک روشِ یکتا محدود نمیکند. این مقاله نه VAD اجرا میکند، نه نویزِ پسزمینه میسازد و نه تنظیمِ کدکِ واقعی را تغییر میدهد.
همچنین هر سامانه الزاماً همین قالبِ جداگانهٔ CN را به کار نمیبرد؛ برخی کدکها قراردادِ خودشان را دارند. نامِ Comfort Noise را با حذفِ نویزِ مزاحم از گفتار یکی نگیرید. این صفحه دربارهٔ معنایِ رویدادها و بایتِ توصیفی است، نه ابزارِ بهبودِ کیفیتِ شنیداری.
شمارهٔ پیوسته، زمانِ ناپیوسته
در دفترِ ساختگی، بستهٔ۱۰ با زمانِ۰ برایِ voice، بستهٔ۱۱ با زمانِ۱۶۰ برایِ CN و بستهٔ۱۲ با زمانِ۸۰۰ برایِ voice برچسب خوردهاند. نوعها را نویسنده اعلام کرده، نه یک مدل از صدا تشخیص داده باشد. ساعتِ فرضی۸۰۰۰ است و مدتِ پوششِ قبلی را۱۶۰تیک در نظر گرفتهایم.
از۱۱به۱۲، شماره فقط یک واحد جلو رفته ولی زمان۶۴۰تیک جلو رفته است. این مشاهده با سکوتِ ارسالشدهٔ ناپیوسته یا قراردادِ دیگری از بستهبندی سازگار است؛ کد آن را اثباتِ یکتایِ DTX نمینامد. اصلِ منبعِ یکسان، نبودِ بازمرتبسازی و معلومبودنِ مدتِ قبلی در این مثال فرض شدهاند.
فاصلهٔ شماره چه شاهدِ دیگری میدهد؟
در جفتِ ساختگیِ دوم، شماره از۱۰به۱۲ و زمان از۰به۳۲۰ رفته است. این بار یک شماره در مشاهدهها خالی است. اما دریافتکنندهٔ دارایِ ثبتِ ناقص، فقط با این دو سطر نمیداند علتْ اتلافِ شبکه، جاافتادگیِ capture یا وضعیتِ دیگری است. نتیجهٔ برنامه عمداً «فاصله در مشاهده» است، نه حکمِ قطعیِ علت.
| دو مشاهدهٔ نمونه | فاصلهٔ شماره | فاصلهٔ زمان | استنتاجِ محدود |
|---|---|---|---|
| ۱۱به۱۲، زمانِ۱۶۰به۸۰۰ | ۱ | ۶۴۰تیک | زمانِ ناپیوسته بدونِ شمارهٔ خالی |
| ۱۰به۱۲، زمانِ۰به۳۲۰ | ۲ | ۳۲۰تیک | شمارهٔ خالی در مشاهدهها |
یک بایتِ CN را چگونه میخوانیم؟
payloadِ ساختگیِ یکبایتیِ۴۰، در قراردادِ همین RFC، سطحِ منفیِ۴۰dBov را نشان میدهد. این واحد به نقطهٔ اضافهبارِ سیستم مربوط است؛ آن را بدونِ قرارداد به dBFSِ فایل یا بلندیِ ادراکیِ LUFS تبدیل نمیکنیم. بیتِ بالایی باید در این قالب صفر باشد و نمونهٔ دارایِ بیتِ یک رد میشود.
نمونهٔ سهبایتیِ۴۰،۱۲۷،۱۵۰ هم خوانده میشود: اولین بایت سطح و دو بایتِ بعد اطلاعاتِ طیفیاند. این بازرس فقط تعداد و hexِ آنها را نگه میدارد؛ ضریبها را رمزگشایی و موجِ نویز را تولید نمیکند. ورودیِ خالی و بیتِ بالاییِ نامعتبر دو آزمونِ منفیِ واقعیاند.
سکوت را علامتِ قطعیِ پایان نگذاریم
اگر مدتی بسته نرسید، سیاستِ timeout باید با قراردادِ همان جریان، وضعیتِ جلسه و ثبتِ مجاز بررسی شود. از یک آستانهٔ دلخواهِ بدونِ شاهد، «مشتری قطع کرد» نسازیم. این تمرین اصلاً پایانِ تماس را تشخیص نمیدهد و هیچ درصدی برایِ صرفهجوییِ پهنایِ باند یا بهبودِ خروجی ارائه نمیکند.
برایِ بررسیِ واقعی، پشتیبانی و مذاکرهٔ قالب، clock، منبع، شماره و محلِ capture را با مسئولِ ارتباط روشن کنید. بایتهایِ نمونهٔ عمومی این صفحه دادهٔ واقعی نیستند؛ فایل یا بستهٔ خصوصی را در فضایِ عمومی منتشر نکنید. یک payloadِ ظاهراً معتبر هم هویت و درستیِ فرستنده را ثابت نمیکند.
بعد از دیدنِ فاصلهٔ بسته، کدام راهنما مفید است؟
جیتر و مهلتِ پخش دیررس را از ناموجود جدا میکند؛ ساعتِ RTP و لنگرِ RTCP واحدِ زمان را روشن میکند. برایِ راهاندازیِ منشیِ تلفنیِ اپرا، نیازِ پاسخِ ورودی و مسیرِ فعلی را مطرح کنید؛ این مقاله وجودِ یک تنظیمِ DTXِ خاص یا پشتیبانیِ CNِ مشخص در محصول را وعده نمیدهد.
فایل تمرین و منبع
دو فاصلهٔ شماره/زمان و دو payloadِ ساختگیِ CN را بررسی کنید · دفترِ برچسبهایِ اعلامی، تفسیرِ محدود و unknownِ علتِ واقعی
منابع در 2026-11-04 خوانده شدند؛ این تاریخ، تاریخ انتشار منبع نیست. مثالها و فایلهای این راهنما آموزشی و ساختهٔ تحریریهاند.