CANCEL وBYE در SIP کارِ یکسانی انجام نمی‌دهند. برایِ پایان‌دادن به تلاشِ برقراریِ تماس، وضعیتِ درخواست و دیالوگ را باید بخوانیم؛ صرفِ زدنِ دکمهٔ قطع یک پیامِ یکتا را در همهٔ وضعیت‌ها تعیین نمی‌کند. این تمرین سیاستِ سادهٔ یک تماس‌گیرنده را بررسی می‌کند که می‌خواهد از تلاش منصرف شود و جلسهٔ پذیرفته‌شده را هم ادامه ندهد.
درخواستِ درانتظار با جلسهٔ پذیرفته‌شده فرق دارد
CANCEL درخواست می‌کند پردازشِ درخواستِ قبلیِ درانتظار متوقف شود؛ رویِ نتیجه‌ای که قبلاً نهایی شده اثرِ بازگشتی ندارد. BYE به یک دیالوگ و جلسهٔ مرتبط مربوط است. این توضیح را به حکمِ «BYE هرگز پیش از پاسخ نیست» تبدیل نکنیم؛ استاندارد برایِ نقش‌ها و دیالوگ‌هایِ early شرایطِ مشخص دارد، اما سیاستِ محدودِ مثالِ ما آن مسیرها را اجرا نمی‌کند.
در کد هیچ سرآیند، socket یا سامانهٔ تلفنی وجود ندارد. رویدادهایِ رشته‌ای مثلِ۱۸۰ِ INVITE و۲۰۰ِ CANCEL، ورودی‌هایِ ساخته‌شدهٔ نویسنده‌اند. نتیجه فقط اقدام‌هایِ همان مدل است، نه اعتبارسنجیِ همهٔ رفتارهایِ مجازِ SIP یا دستورِ آمادهٔ تنظیمِ سانترال.
اگر هنوز پاسخِ موقت نرسیده چه می‌کنیم؟
در حالتِ اول کاربرِ فرضی پیش از رویدادِ۱۸۰ درخواستِ قطع می‌دهد. مدل همان لحظه CANCEL منتشر نمی‌کند؛ خواسته را نگه می‌دارد و پس از پاسخِ موقت اقدام می‌کند. بعد۲۰۰ِ CANCEL و۴۸۷ِ INVITE می‌رسند و برایِ پاسخِ غیرموفقِ INVITE، رویدادِ ACKِ مربوط ثبت می‌شود. زمان‌بندیِ مهلت و retransmission در این مدل نیست.
این نمونه کمک می‌کند در گزارش، «کاربر قطع را خواست» را از «پیامِ لغو فرستاده شد» جدا بنویسیم. نبودِ پیامِ فوری در یک مرحله، لزوماً به معنیِ نادیده‌گرفتنِ دکمه نیست؛ باید قراردادِ همان پیاده‌سازی و وضعیتِ درخواست را هم دید.
رقابتِ لغو و پذیرش را در دفتر دنبال کنیم
در حالتِ دوم۱۸۰ رسیده و سپس درخواستِ قطع باعثِ CANCEL می‌شود.۲۰۰ِ CANCEL می‌آید، اما هنوز وضعیتِ INVITE معلوم نیست. بعد۲۰۰ِ INVITE می‌رسد: در این مدلِ «ادامه نده»، ACK و سپسBYE ثبت می‌شوند. موفقیتِ درخواستِ لغو را با تضمینِ لغوشدنِ تمامِ نتیجهٔ تماس یکی نگرفته‌ایم.
| خطِ زمانِ ساختگی | اقدام‌هایِ ثبت‌شدهٔ مدل |
|---|---|
| قطع پیش از۱۸۰، سپس۴۸۷ | CANCEL پس از۱۸۰، ACKِ غیر۲xx |
| قطع پس از۱۸۰، پذیرش در راه | CANCEL، سپسACK وBYE |
| پذیرش، سپس درخواستِ قطع | ACK، سپسBYE |
| فقط۲۰۰ِ OPTIONS، بدونِ پاسخِ INVITE | هیچ اقدامِ تازهٔ این مدل |
برایِ فهمیدنِ نتیجه، روشِ پاسخ را حفظ کنیم
کد واقعاً کنترل می‌کند۲۰۰ِ CANCEL وضعیتِ INVITE را پذیرفته‌شده نمی‌کند.۲۰۰ِ OPTIONS هم در سناریویِ چهارم جایِ پاسخِ INVITE نمی‌نشیند. نمونهٔ سوم نشان می‌دهد پس از پذیرش و ACK، خواستهٔ قطع در سیاستِ ما بهBYE می‌رسد. ترتیبِ کاملِ رویدادها در JSON آمده و به یک برچسبِ کلیِ «OK» خلاصه نشده است.
این دفتر برایِ آموزش است: تطبیقِ Call-ID،tag،CSeq وbranch، شاخه‌هایِ هم‌زمان، پیامِ تکراری، خطایِ شبکه و نقشِ طرفِ مقابل پیاده نشده‌اند. یک محصولِ عملیاتی به ماشینِ حالتِ کامل و آزمون‌هایِ بیشتری نیاز دارد؛ این تابع را به تماسِ واقعی متصل نکرده‌ایم.
قطعِ تماس را با نتیجهٔ تجاری یکی ندانیم
از این رویدادها کیفیتِ مکالمه، مدتِ صورتحساب یا رضایتِ مشتری استخراج نشده است. برایِ عیب‌یابیِ واقعی، شناسهٔ پوشانده‌شده، نقشِ طرف، روشِ درخواست و پاسخ و نقطهٔ ثبت را با مسئولِ فنی بررسی کنید. کامل‌بودنِ لاگ را هم روشن کنید؛ نبودِ یک پیام در تصویرِ ناقص، نبودِ قطعیِ آن در شبکه نیست.
در بوق وEarly Media می‌بینید چرا شنیدنِ صدا هم شاهدِ کافیِ پاسخ نیست. نقشهٔ خط و سانترال مسئولیتِ هر قسمت را جدا می‌کند. برایِ درخواستِ منشیِ تلفنیِ اپرا، سناریویِ قطع و نتیجهٔ موردِ انتظار را مطرح کنید؛ این مثال رفتارِ داخلیِ محصول یا خطِ شما را اعلام نمی‌کند.
فایل تمرین و منبع
چهار خطِ زمانِ پایانِ تلاشِ تماس را در مدلِ محلی اجرا کنید · هر رویداد، اقدامِ مدل و وضعیتِ نهاییِ INVITE را ببینید
منابع در 2026-11-04 خوانده شدند؛ این تاریخ، تاریخ انتشار منبع نیست. مثال‌ها و فایل‌های این راهنما آموزشی و ساختهٔ تحریریه‌اند.