یک فشارِ دکمهٔ تلفن ممکن است چند بستهٔ telephone-event بسازد. اگر هر بسته یا هر گزارشِ پایان را یک انتخابِ تازه بشماریم، همان کلید چند بار وارد منو می‌شود. در این تمرین، هفت بستهٔ ساختگی را می‌خوانیم و فقط دو رویدادِ پایان‌یافته تحویل می‌دهیم؛ سه تکرارِ پایانِ فشار اول، سه بار شماره‌گیری نیست.
قبل از شمارش، قراردادِ ورودی را معلوم کنیم
RFC4733 رویدادهای تلفنی را در RTP توصیف می‌کند. payload سادهٔ این تمرین چهار بایت دارد: شمارهٔ رویداد، بیتِ پایان E و حجم صدا، سپس duration دو‌بایتی با ترتیب بایتِ شبکه. ما فقط رقم‌های۰تا۹ و رویداد کوتاهِ بدون قطعه‌بندی را پشتیبانی می‌کنیم. کد، سرآیند RTP یا بستهٔ واقعی شبکه را باز نمی‌کند؛ session،SSRC،timestamp وsequence از دفترِ اصیلِ تمرین می‌آیند.
ساعتِ۸۰۰۰ در فایل یک قراردادِ اعلامیِ مثال است؛ آن را برای همهٔ payloadها ثابت فرض نکنید. timestamp آغازِ رویداد را نگه می‌دارد و durationِ گزارش‌های بعدی مدتِ تجمعیِ همان رویداد است. با تغییرِ sequence به‌تنهایی فشارِ تازه‌ای آغاز نشده است. نگاشت و ساعت باید قبلاً در مسیرِ مجاز مذاکره شده باشند.
هویتِ رویداد را از هویتِ بسته جدا کنیم
کلیدِ داخلیِ این نسخه از session،SSRC،timestamp شروع و شمارهٔ رویداد ساخته می‌شود. برای فشار اول، رقم۵ با آغاز۳۲۰۰۰ دو گزارشِ میانیِ۱۶۰و۶۴۰tick دارد؛ سپس سه گزارشِ پایان با مدت۸۰۰ می‌آیند. گزارشِ اول پایان، یک رویداد می‌سازد؛ دو تکرار بعدی فقط به همان رویدادِ بسته‌شده اشاره می‌کنند.
فشار دوم باز هم رقم۵ است، اما timestamp آغاز۴۸۰۰۰ دارد. یک گزارشِ میانیِ۲۴۰ و یک پایانِ۶۴۰ دارد و بنابراین رویداد تازه محسوب می‌شود. این فرق برای منویی که انتخاب‌های تکراری را مجاز می‌داند مهم است: نباید همهٔ۵ها را حذف کرد؛ باید تکرارِ انتقالِ یک فشار را از فشارِ دوم جدا کرد.
| توالیِ ساختگی | آغاز و مدت | رفتارِ تمرین |
|---|---|---|
| ۱۰۰،۱۰۱ | ۳۲۰۰۰؛۱۶۰و۶۴۰ | به‌روزرسانی، بدون خروجی نهایی |
| ۱۰۲ | ۳۲۰۰۰؛پایان۸۰۰ | یک۵ با مدت۰٫۱ثانیه |
| ۱۰۳،۱۰۴ | تکرارِ همان پایان | خروجی تازه نمی‌سازند |
| ۱۰۵،۱۰۶ | ۴۸۰۰۰؛۲۴۰وپایان۶۴۰ | ۵دوم با مدت۰٫۰۸ثانیه |
اگر پایان نرسیده باشد، چه گزارش کنیم؟
فقط دو بستهٔ اول را هم جدا اجرا کرده‌ایم: فهرستِ پایان‌یافته خالی و یک هویتِ ناتمام باقی می‌ماند. این نمونه سیاستِ timeout و بازیابیِ اتلاف را حل نمی‌کند؛ از نبودِ پایان، «کلید دریافت نشد» یا «کلید کامل شد» نتیجه نمی‌گیرد. در پیاده‌سازیِ واقعی، سیاستِ رویدادِ ناقص، طول عمرِ حافظه و رفتارِ منو باید صریح و جدا آزموده شوند.
یک بستهٔ میانیِ دیررس با sequence۹۹ بعد از پایان، رویداد را دوباره باز نمی‌کند. همان رقم و آغاز با SSRC متفاوت نیز رویدادِ جدا می‌شود؛ این مورد واقعاً اجرا شده است. در این مدلِ محدود، پایانِ تکراری با duration متفاوت خطای قرارداد می‌دهد؛ چنین خطایی را رفتار جامعِ همهٔ شبکه‌ها معرفی نمی‌کنیم.
بیتِ رزرو و طولِ صفر را حدس نزنیم
گیرنده طبق RFC بیتِ رزرو R را نادیده می‌گیرد؛ مثالِ فرستندهٔ عادی آن را صفر می‌گذارد. کد با تغییر همین بیت، یکسان‌ماندنِ فیلدهای خوانده‌شده را کنترل می‌کند. duration صفر برای رقمِ DTMFِ این تمرین نادیده گرفته می‌شود؛ آن را وضعیتِ دائمیِ یک رویدادِ state نمی‌نامیم. payload سه‌بایتی هم واقعاً رد می‌شود.
رویدادهای طولانیِ قطعه‌ای، RFC2198، دورزدنِ timestamp، همهٔ جابه‌جایی‌ها و بازیابیِ همهٔ اتلاف‌ها خارج از این فایل‌اند. هیچ تماس، ارسالِ RTP یا اجرای سانترال انجام نشده است. خروجیِ تمرین شاهدِ سازگاریِ خط یا قابلیتِ فعالِ یک محصول نیست.
از خروجی فنی تا انتخابِ معتبرِ منو
طراحی مسیر DTMF می‌گوید یک کلید در هر مرحله چه معنایی دارد؛ این صفحه پیش از آن، گزارش‌های تکراریِ انتقال را جمع می‌کند. توافقِ قالب در SDP نیز صرفاً پیش‌شرطِ مذاکره است و این بازسازی را انجام نمی‌دهد.
برای بررسیِ منشی تلفنی اپرا، منوی کوتاه، نوعِ خط و رفتارِ مورد انتظارِ کلیدِ تکراری یا ناقص را همراه درخواست ارائه کنید. فعال‌بودنِ دریافت کلید و جزئیاتِ زیرساخت باید جدا بررسی شود؛ خروجیِ آموزشیِ این صفحه وعدهٔ اتصالِ فوری نیست.
فایل تمرین و منبع
کد کامل تمرین محلی و کنترل‌های ورودی · دادهٔ ساختگی و خروجیِ اجرای واقعیِ تمرین
منابع در 2026-11-04 خوانده شدند؛ این تاریخ، تاریخ انتشار منبع نیست. مثال‌ها و فایل‌های این راهنما آموزشی و ساختهٔ تحریریه‌اند.