MRCPv2 پروتکلی برای کنترل منابع پردازش رسانه، مانند موتور تشخیص گفتار و تولید گفتار، روی شبکه است. خود آن تمام مراحل اتصال را مستقل انجام نمی‌دهد؛ در معماری استاندارد، پروتکل‌های دیگر برای برقراری جلسه، توصیف قابلیت‌ها و انتقال رسانه نقش دارند. داشتن صدای فارسی خوب، به‌تنهایی پشتیبانی از MRCP را ثابت نمی‌کند.
سه لایه را روی یک نقشه بکشیم
در یک طرح آموزشی، برنامهٔ تلفنی می‌خواهد از موتور گفتار جداگانه استفاده کند. ابتدا باید جلسه و قابلیت‌های دو سر مشخص شوند؛ سپس درخواست کنترل به منبع گفتار برسد و جریان رسانه از مسیر مربوط عبور کند. اگر همهٔ این‌ها را «API صدا» بنامیم، پیدا نمی‌کنیم خطا در کدام قرارداد رخ داده است.
| لایه | نقش در طرح استاندارد | پرسش عیب‌یابی |
|---|---|---|
| جلسه و توصیف | SIP و SDP برای هماهنگی و پارامترها | منبع و قابلیت لازم توافق شده‌اند؟ |
| کنترل منبع | درخواست و رویداد MRCP | کدام درخواست با چه شناسه‌ای در چه وضعیتی است؟ |
| رسانه | مسیر صوتِ توافق‌شده | صدای مربوط به همان جلسه عبور می‌کند؟ |
پذیرفته‌شدن درخواست با پایان آن یکی نیست
در مثال ساختگی، برنامه درخواست تولید گفتار را می‌فرستد. ثبت پذیرفته‌شدن یا درحال‌انجام‌بودن، به معنی تکمیل خروجی نیست؛ رویداد پایان و علت آن هم باید با همان شناسه بررسی شود. به همین شکل، بازشدن یک مسیر شبکه نمی‌گوید متن درست شنیده یا گفتار درست تولید شده است. در این نوشته هیچ پیام واقعی MRCP ارسال نشده است.
برگهٔ همراه سه شاهد را جدا می‌کند: وضعیت جلسه، وضعیت درخواست و شاهد رسانه. در سناریوی آموزشی، اگر درخواست تمام شده اما در سمت شنونده صدایی ثبت نشده، نباید با تغییر متن ورودی نتیجه گرفت مسئله حل شده است. مسیر رسانه و نقطهٔ مشاهده باید معلوم باشند. این برگه جای تحلیل کامل ردپای پروتکل را نمی‌گیرد؛ کمک می‌کند مسئله به تیم درست ارجاع شود.
چرا CTI یا وب‌سرویس معمولی را همان MRCP ننامیم؟
CTI می‌تواند رویداد تلفن را به میزکار یا پرونده وصل کند. هدف MRCP کنترل منبع گفتار است؛ وجود یکی، پشتیبانی دیگری را نتیجه نمی‌دهد. یک وب‌سرویس تبدیل فایل صوتی هم می‌تواند قرارداد کاملاً متفاوتی داشته باشد. روش اتصال را از نام محصول یا پسوند پاسخ حدس نزنید.
در معماری ایجنت صوتی، تبدیل گفتار به متن و متن به گفتار نقش‌های جدا دارند. اینکه این نقش‌ها با چه پروتکل و نسخه‌ای متصل شوند، تصمیم اجرایی همان پروژه است؛ استاندارد پایهٔ MRCPv2 به‌تنهایی نقشهٔ همهٔ محصولات امروز نیست.
برای بررسی سازگاری چه بپرسیم؟
نام و نسخهٔ سامانهٔ تلفنی، منبع گفتار موردنیاز، نسخهٔ پروتکل، قالب و مسیر رسانه، زبان لازم، رویداد پایان و نحوهٔ گزارش خطا را ثبت کنید. برای هر مورد، پاسخ مکتوب و سپس آزمون مجاز همان اتصال لازم است. برگهٔ بدون شاهد را «سازگار» علامت نزنید و رمز یا دادهٔ مشتری را در نمونهٔ عمومی نگذارید.
برای خدمت فارسی، نیاز خود را در اپرانگار، گفتار به متن یا اپراگو، متن به گفتار مطرح کنید. روش ارائهٔ فعلی از مسیر درخواست و راه‌اندازی تیم است؛ وجود MRCP یا اتصال آماده به یک سانترال مشخص هنوز باید برای همان پروژه بررسی شود.
فایل همراه و منبع اصلی
دریافت برگهٔ CSV این راهنما؛ همهٔ نام‌ها و وضعیت‌ها آموزشی‌اند. ستون نتیجهٔ واقعی فقط پس از بررسی مجاز پروژه تکمیل شود.
تاریخ مطالعهٔ منبع: ۳ نوامبر ۲۰۲۶. استانداردهای پایهٔ قدیمی را خبر تازه معرفی نمی‌کنیم؛ برای نسخهٔ اجرایی، مستندات همان سامانه و به‌روزرسانی‌ها لازم است.