در SIP، Max-Forwards بودجهٔ تعدادِ ارسال‌هایِ رو به جلوِ یک درخواست را محدود می‌کند. اگر درخواست پیش از رسیدن به مقصد این بودجه را تمام کند، خطایِ۴۸۳ می‌تواند دیده شود. این محدودیت جایِ اصلاحِ مسیرِ حلقه‌ای را نمی‌گیرد. برایِ یافتنِ علت، توالیِ واقعیِ گره‌ها و مقدارِ دریافتی و ارسالی را کنارِ هم بخوانید؛ فقط عددِ اولیه را زیاد نکنید.
حلقه را در مسیر ببینیم، نه فقط در نامِ خطا
در نمونهٔ کاملاً ساختگی، A درخواست را به B، B به C و C دوباره به B می‌فرستد. مقصدِ موردِ نظر D است و بودجهٔ آغازینِ تمرین پنج است. هیچ سرور، شماره، تنظیمِ سانترال یا شبکه‌ای در این برنامه وجود ندارد؛ نام‌ها فقط گره‌هایِ یک نگاشتِ محلی‌اند.
ردِ اجرا A۵،B۴،C۳،B۲،C۱ وB۰ را ثبت می‌کند. پنج ارسال انجام شده و گرهِ با بودجهٔ صفر بدونِ ارسالِ بعدی رد می‌کند. تکرارِ B وC در این نگاشت، شاهدِ چرخهٔ ساخته‌شده است. خودِ کد نیز تعدادِ شش بازدید و کم‌شدنِ دقیقِ یک واحد در هر ارسال را کنترل می‌کند.
۴۸۳ به‌تنهایی اثباتِ حلقه نیست
در نمونهٔ دوم مسیر A→B→C→D کاملاً بدونِ چرخه است، اما بودجه را یک گذاشته‌ایم. A یک بار می‌فرستد و B با بودجهٔ صفر متوقف می‌شود. نتیجهٔ مدل باز هم۴۸۳ است؛ درحالی‌که علت، کوتاه‌بودنِ بودجه برایِ همین مسیر بوده است. این ضدنمونه کمک می‌کند نامِ خطا را بی‌بررسی به یک علتِ یکتا ترجمه نکنیم.
| مسیرِ دست‌ساز | بودجهٔ آغاز | نتیجهٔ مدل |
|---|---|---|
| A→B→C→B | ۵ | تکرارِ گره و توقفِ بودجه |
| A→B→C→D | ۱ | توقف، با وجودِ مسیرِ بدونِ حلقه |
| A→B→C→D | ۳ | تحویل به مقصدِ تعریف‌شدهٔ تمرین |
مدلِ ساده چه چیزی را پیاده نکرده است؟
برنامه نگاشتِ یک‌خروجی برایِ هر گره دارد؛ مسیریابیِ واقعیِ SIP، Via، branch، fork، DNS، احرازِ هویت یا تشخیصِ loopِ کامل را پیاده نکرده‌ایم. تحویل به مقصدِ D فقط پایانِ همین نگاشت است و معنیِ پاسخِ تماس، شنیده‌شدنِ صوت یا موفقیتِ فروش ندارد. دربارهٔ ترافیکِ واقعی از این fixture نتیجهٔ عملکرد نمی‌گیریم.
چهار مقدارِ نامعتبرِ منفی،۲۵۶،بولی و اعشاری هم واقعاً رد می‌شوند. این بررسی برایِ قراردادِ ورودیِ برنامه است؛ اعتبارسنجِ همهٔ سرآیندهایِ SIP نیست. مقدارِ یک یا پنج در مثال، توصیهٔ تنظیمِ شبکهٔ عملیاتی نیست؛ مرجعِ اصلی مقدارِ آغازین و قواعدِ پراکسی را جدا تعریف می‌کند.
برگهٔ عیب‌یابی را چگونه تکمیل کنیم؟
برایِ یک درخواستِ مجاز، شناسهٔ هم‌بستگیِ پوشانده‌شده، زمان، گرهٔ دریافت‌کننده، مقصدِ بعدی، روش و Max-Forwardsِ ورودی/خروجی را ثبت کنید. اگر گره دوباره دیده شد، بررسی کنید همان درخواستِ درحالِ چرخش است یا بازدیدِ مشروعِ دیگری با وضعیتِ متفاوت؛ اسمِ گره به‌تنهایی هم‌بستگیِ کامل ایجاد نمی‌کند.
تصمیمِ اصلاح باید به قاعدهٔ مسیر وصل شود: مثلاً چرا C دوباره B را انتخاب کرده است؟ در پروژهٔ واقعی ممکن است انتقالِ نامناسب یا نگاشتِ مقصد مسئله باشد، اما این برنامه علتِ شبکهٔ شما را تشخیص نداده است. تغییر را با مسئولِ همان زیرساخت و مسیرِ بازگشتِ مشخص بررسی کنید؛ از رویِ مقاله تنظیمِ کور انجام ندهید.
پس از اصلاحِ مسیر، چه شاهدی لازم است؟
همان سناریویِ مجاز را دوباره بررسی کنید و مسیرِ قبل/بعد را با قراردادِ یکسان مقایسه کنید. رسیدن به D در نمونهٔ سوم فقط شاهدِ کفایتِ بودجه و نگاشتِ همان مدل است. رسیدنِ سیگنالِ تماس و عبورِ رسانهٔ دوطرفه هنوز بررسی‌هایِ جدا هستند؛ شمارِ پرش کمتر هم خودکار کیفیتِ صوت یا هزینهٔ کمتر را ثابت نمی‌کند.
نقشهٔ خط و سانترال مسئولیتِ هر قسمت را روشن می‌کند؛ مرزِ سیگنالینگ و رسانه کمک می‌کند نتیجه‌ها را قاطی نکنیم. برایِ اتصالِ پاسخ‌گویِ ورودی، وضعیتِ مسیرِ فعلی را در درخواستِ منشیِ تلفنیِ اپرا مطرح کنید؛ این نوشته سازگاریِ خودکارِ هر شبکه‌ای را وعده نمی‌دهد.
فایل تمرین و منبع
سه مسیرِ محلی با بودجهٔ پرش و ردِ بدونِ ارسال را اجرا کنید · همهٔ گره‌ها، بودجهٔ دریافتی/ارسالی و نتیجهٔ هر مسیر
منابع در 2026-11-04 خوانده شدند؛ این تاریخ، تاریخ انتشار منبع نیست. مثال‌ها و فایل‌های این راهنما آموزشی و ساختهٔ تحریریه‌اند.