پاسخِ موفق به REFER فقط می‌گوید درخواستِ ارجاع پذیرفته شده است؛ نتیجهٔ اقدامِ ارجاع‌شده را باید از NOTIFYِ همان subscription خواند. حتی پاسخِ۲۰۰به خودِ NOTIFY با وضعیتِ داخلِ بدنهٔ message/sipfrag یکی نیست. در این تمرین، دو ارجاعِ ساختگی با پاسخ‌های تحویلِ یکسان، به دو نتیجهٔ۲۰۰و۵۰۳می‌رسند.
سه وضعیت را در یک «OK» خلاصه نکنیم
لایهٔ اول پاسخِ خودِ REFER است. لایهٔ دوم پاسخِ تراکنشِ تحویلِ هر NOTIFY است. لایهٔ سوم status line داخلِ بدنهٔ sipfrag است که پیشرفت یا نتیجهٔ درخواستِ ارجاع‌شده را گزارش می‌کند. اگر هر عددِ۲۰۰را «انتقال موفق» بنامیم، شکستِ۵۰۳ِ داخلِ بدنه هم ممکن است پشتِ تحویلِ موفقِ گزارش پنهان شود.
فایل هیچ پیامِ شبکه یا تماسِ واقعی ندارد. recordها را نویسنده ساخته و هویتِ subscription از قبل مشخص شده است. خوانندهٔ محدود فقط یک خطِ وضعیتِ SIP/2.0 با CRLF را از بدنه می‌پذیرد؛ parserِ عمومیِ همهٔ پیام‌های SIP، MIME، احراز هویت یا همهٔ ترتیب‌های مجازِ استاندارد نیست.
ارجاعِ پذیرفته‌شده الزاماً۲۰۲نیست
RFC3515 پایهٔ REFER را توضیح می‌دهد، اما باید به‌روزرسانیِ RFC7647 را هم خواند. نسخهٔ به‌روزشده پاسخِ پذیرفته‌شدن را۲۰۰می‌داند و۲۰۲را منسوخ می‌کند؛ اگر۲۰۲قدیمی دریافت شود، مانند پذیرشِ۲۰۰تفسیر می‌شود. کد این سازگاریِ دریافت را جدا اجرا می‌کند و آن را نتیجهٔ نهاییِ کار نمی‌نامد.
برای جلوگیری از ابهامِ dialog، هر ارجاعِ جدیدِ این مثال subscription dialog جدا و هدفِ اعلام‌شدهٔ GRUU-capable دارد. این شرطِ آموزشی در خروجی نوشته شده است؛ دو REFERِ جدید را بی‌توضیح در دیالوگِ موجودِ تماس قرار نداده‌ایم. ارتباط با تماسِ پیشین و Target-Dialog را این فایل parse نمی‌کند؛ پیکربندی و قواعدِ اجرایی باید با مستندِ همان سامانه سنجیده شوند.
دو trace را با هویتِ درست دنبال کنیم
هویتِ نرمال‌شده از Call-ID،tagِ محلی،tagِ دور و Event-idِ اعلامی ساخته می‌شود. مثالِ اول شناسهٔ۴۱و مثالِ دوم۵۲دارد. این‌ها شمارهٔ مشتری یا نتیجهٔ فروش نیستند؛ فقط correlationِ گزارش‌ها را روشن می‌کنند. دریافتِ NOTIFYِ ناشناخته خطا می‌دهد و به آخرین REFERِ دیده‌شده نسبت داده نمی‌شود.
| ارجاعِ آموزشی | پاسخِ REFER | بدنهٔ NOTIFY | پاسخ به NOTIFY |
|---|---|---|---|
| A | ۲۰۰ | ۱۸۰،سپس۲۰۰ | برای هر دو۲۰۰ |
| B | ۲۰۰ | ۱۰۰،سپس۵۰۳ | برای هر دو۲۰۰ |
گزارش‌های دو subscription عمداً در هم آمده‌اند: نتیجهٔ نهاییِ B پیش از A می‌رسد. تابع با هویت، نه ترتیبِ آخرین درخواست، هرکدام را در سبد خودش می‌گذارد. خروجیِ A موفقیتِ SIPِ درخواستِ ارجاع‌شده و خروجیِ B شکستِ SIP است؛ هر دو گزارششان با۲۰۰تحویل گرفته شده‌اند.
نبودِ نتیجهٔ نهایی را نامعلوم نگه داریم
همان داده را پس از دو NOTIFYِ موقت قطع می‌کنیم. هیچ‌یک نتیجهٔ نهایی ندارد و هردو unknown_no_final_notify می‌شوند. پذیرفته‌شدنِ REFER یا شنیدنِ وضعیتِ زنگ، مجوزِ پرکردنِ خودکارِ «انجام شد» نیست. زمانِ انتظار، تمدیدِ subscription و بازیابیِ پیامِ ازدست‌رفته در کد پیاده نشده‌اند.
RFC اجازهٔ رسیدنِ NOTIFY پیش از پاسخِ REFER را هم توضیح می‌دهد؛ readerِ کوچکِ ما از recordهای نرمال‌شدهٔ پس از پذیرش شروع می‌کند و آن رقابت را پوشش نمی‌دهد. همین‌طور retransmission، کلِ ماشینِ حالتِ RFC6665 و خاتمهٔ subscription اجرا نشده است. محدودبودنِ reader به معنیِ نامعتبر بودنِ سایر traceهای استاندارد نیست.
نتیجهٔ فنی را با پذیرشِ انسان یکی نگیریم
حتی sipfrag۲۰۰نشان نمی‌دهد شخصِ درست پاسخ داده، توضیح را فهمیده یا موضوعِ مشتری حل شده است. برای گزارشِ تجاری شاهدِ جدا لازم است. این تمرین فقط خواندنِ سیگنالِ ارجاع را کنترل می‌کند؛ انتقالِ گرم، اطلاع‌رسانی به اپراتور، ثبتِ CRM و صورتحساب را انجام نمی‌دهد.
دفترِ CANCEL وBYE هم اهمیتِ روشِ پاسخ و وضعیت را نشان می‌دهد، اما مسئلهٔ اینجا correlation و بدنهٔ NOTIFY است. نقشهٔ اتصال مسئولِ بررسیِ هر جزء را پیش از آزمونِ زنده روشن می‌کند.
برای بررسیِ مسیرِ ارجاع در منشی تلفنی اپرا، مقصد، اختیارِ ارجاع و شاهدِ نهاییِ مورد انتظار را تعریف کنید. trace فقط با پوشاندنِ دادهٔ خصوصی و از مسیرِ مجاز بررسی شود. این مقاله وجودِ REFER،GRUU یا انتقالِ آماده در همهٔ پروژه‌های اپرا را تضمین نمی‌کند.
فایل تمرین و منبع
کد کامل تمرین محلی و کنترل‌های ورودی · دادهٔ ساختگی و خروجیِ اجرای واقعیِ تمرین
- RFC3515، آوریل۲۰۰۳؛ بخش۲٫۴، وضعیتِ NOTIFY، sipfrag و correlation؛ همراه با به‌روزرسانیِ بعدی خوانده شود
- RFC7647، سپتامبر۲۰۱۵؛ GRUU، محدودیتِ استفادهٔ دوباره از dialog و منسوخ‌شدنِ۲۰۲؛ بخش‌های۳تا۵ خوانده شدند
منابع در 2026-11-04 خوانده شدند؛ این تاریخ، تاریخ انتشار منبع نیست. مثال‌ها و فایل‌های این راهنما آموزشی و ساختهٔ تحریریه‌اند.