در REGISTER، زمانِ انقضای درخواستی الزاماً همان زمانِ اعطاشده نیست. برای فهمیدنِ تمدیدِ ثبتِ SIP باید bindingِ متعلق به خودِ دستگاه را در پاسخ پیدا کنیم، زمانِ تأییدِ آن پاسخ را نگه داریم و پاسخِ نامعلوم را با تمدیدِ موفق یکی نگیریم. تمرینِ این صفحه یک دفترِ زمانیِ کاملاً ساختگی را با کد محلی دنبال می‌کند؛ به registrar یا خط واقعی وصل نمی‌شود.
bindingِ کدام دستگاه را می‌خوانیم؟
در دادهٔ آموزشی، یک نشانیِ تماس متعلق به UAِ خودمان و یک Contact متعلق به دستگاهِ دیگر است. هر دو روی نشانی‌های مستنداتیِ۱۹۲٫۰٫۲ قرار دارند؛ نام یا رمزِ واقعی در فایل نیست. پاسخِ ساختگیِ موفق در زمانِ صفر برای Contactِ ما۱۲۰ثانیه و برای دستگاهِ دیگر۹۰۰ثانیه اعتبار اعلام می‌کند.
کد فقط تطبیقِ دقیقِ رشتهٔ Contactهای از پیش نرمال‌شده را انجام می‌دهد؛ قواعدِ هم‌ارزیِ عمومیِ SIP URI، parserِ سرآیند، احراز هویت و رفتارِ همهٔ registrarها در آن نیست. طولِ۹۰۰ثانیهٔ دستگاهِ دیگر را به خطِ خودمان نسبت نمی‌دهیم. همین اشتباه ممکن است در تصویرِ بریدهٔ یک لاگ پنهان بماند.
۳۰۰ثانیه خواسته‌ایم،۱۲۰ثانیه گرفته‌ایم
درخواستِ اولیه عددِ۳۰۰ را پیشنهاد می‌کند، اما در پاسخ، expiresِ Contactِ خودمان۱۲۰است. مرزِ آخرین عمرِ تأییدشده در مدل، زمانِ پاسخ به‌علاوهٔ همین مقدار است:۰+۱۲۰=۱۲۰. جدولِ تمرین، عددِ درخواست‌شده را جدا نگه می‌دارد تا نرم‌افزار اشتباهاً تا۳۰۰صبر نکند.
| رویدادِ ساختگی | شاهدِ موجود | برداشتِ محدود |
|---|---|---|
| پاسخ در۰ | Contactِ خودمان با۱۲۰ | مرزِ تأییدشده۱۲۰ |
| query در۶۰، بدون Contact | پاسخ با۶۰ثانیهٔ باقی‌مانده | همان مرز۱۲۰؛ تمدید نیست |
| تمدید در۹۰، پاسخ در۹۱ | اعطای۱۲۰ثانیهٔ تازه | مرزِ تأییدشده۲۱۱ |
پرس‌وجو با تمدید فرق دارد
REGISTERِ بدون Contact در این بحث برای پرس‌وجوی bindingهاست و آن‌ها را تغییر نمی‌دهد. پاسخِ نمونه در ثانیهٔ۶۰، برای ما۶۰ثانیه و برای Contactِ دیگر۸۴۰ثانیهٔ باقی‌مانده نشان می‌دهد. تابع، مرزِ ما را۶۰+۶۰=۱۲۰به دست می‌آورد؛ عددِ۱۲۰ِ اولیه را از نو به زمانِ۶۰نمی‌چسباند.
سپس سناریوی مستقلِ تمدید را داریم: درخواست در۹۰ فرستاده و پاسخِ موفق در۹۱ دریافت شده است. فقط در این شاخه شواهدِ تأییدشدهٔ تازه داریم. زمان‌های عددیِ فایل، محورِ آموزشیِ واحدند؛ تأخیر، اختلافِ ساعت و محاسبهٔ عملیاتیِ دقیقِ زمان‌بندی در شبکه پیاده نشده‌اند.
اگر پاسخِ تمدید گم شود، انقضا را قطعی ننامیم
سناریوی سوم درخواستِ تمدید دارد ولی پاسخِ آن معلوم نیست. وضعیت در۱۰۰و حتی۱۲۱، unknown_after_unanswered_refresh گزارش می‌شود. ممکن است سرور درخواست را پذیرفته باشد و فقط پاسخ به ما نرسیده باشد؛ عبور از مرزِ قدیمی، وضعیتِ فعلیِ سرور را ثابت نمی‌کند. اینجا «آخرین شاهدِ من قدیمی شد» با «سرور قطعاً ثبت ندارد» فرق دارد.
در شاخهٔ بدونِ هیچ تمدیدِ تأییدشده،۱۲۱از آخرین عمرِ معلوم گذشته است و کد همین گزارهٔ تاریخی را می‌گوید. در تمامِ خروجی‌ها currently_registered_proven نادرست است؛ حتی پاسخِ موفقِ قبلی شاهدِ آنلاین‌بودنِ الان، دسترس‌پذیریِ شبکه یا امکانِ مکالمهٔ دوطرفه نیست. این محدودیت را از نامِ وضعیت‌ها حذف نکرده‌ایم.
حذفِ bindingِ خودمان را جدا ثبت کنیم
در مثالِ حذف، برداشتنِ Contactِ خودمان با expires=۰ در ثانیهٔ۱۰۰ درخواست و پاسخِ آن در ثانیهٔ۱۰۱ دریافت می‌شود. فهرستِ آن فقط Contactِ دستگاهِ دیگر را دارد و مدل نبودِ bindingِ خودمان در همان پاسخ را ثبت می‌کند. حذفِ دستگاهِ دیگر، پاک‌کردنِ همهٔ ثبت‌ها یا تنظیمِ زندهٔ خط انجام نشده است.
فایلِ نتیجه، ورودی، پاسخ‌ها و وضعیتِ هر سناریو را کنار هم دارد؛ کد همهٔ مرزهای۱۲۰و۲۱۱، queryِ بی‌تمدید، دو زمانِ پاسخِ نامعلوم و حذفِ خودمان را واقعاً کنترل می‌کند. این دفتر شبیه‌سازِ شبکه یا ابزارِ تغییرِ تنظیمات نیست؛ هیچ رمز، socket، پیام یا تماس ندارد.
این شاهد را در نقشهٔ اتصال قرار بدهیم
نقشهٔ خط و سانترال مسئولیتِ اجزا را روشن می‌کند؛ اینجا عمرِ bindingِ یک UA را می‌خوانیم. CANCEL وBYE به وضعیتِ تلاش و جلسه مربوط‌اند و تاریخِ ثبت را تعیین نمی‌کنند.
برای درخواستِ بررسیِ منشی تلفنی اپرا، نام و نسخهٔ سامانه، مالکِ فنی و traceِ پوشانده‌شدهٔ مجاز را آماده کنید. رمزِ خط را در فرم عمومی نگذارید. موفقیتِ REGISTER به‌تنهایی وعدهٔ اتصال، صدای دوطرفه یا فعال‌بودنِ خدمتِ اپرا نیست؛ هرکدام بررسیِ خودش را می‌خواهد.
فایل تمرین و منبع
کد کامل تمرین محلی و کنترل‌های ورودی · دادهٔ ساختگی و خروجیِ اجرای واقعیِ تمرین
منابع در 2026-11-04 خوانده شدند؛ این تاریخ، تاریخ انتشار منبع نیست. مثال‌ها و فایل‌های این راهنما آموزشی و ساختهٔ تحریریه‌اند.