طلبات SIP تُسمّى بطريقة. يعرّف RFC 3261 ستًا: INVITE (بدء جلسة)، وACK (تأكيد استجابة INVITE نهائية)، وBYE (إنهاء جلسة)، وCANCEL (إلغاء INVITE معلَّقة)، وREGISTER (تسجيل موقع)، وOPTIONS (الاستعلام عن القدرات). وتضيف مواصفات الامتداد INFO وPRACK وUPDATE وSUBSCRIBE/NOTIFY وREFER وMESSAGE وPUBLISH.
الطرق الست الأساسية
يعرّف RFC 3261 مجموعة الطلبات الأساسية التي يدعمها كل تنفيذ SIP. تُنشئ INVITE جلسة وتحمل عرض SDP الأولي. وتُقرّ ACK استجابة نهائية لـ INVITE — وهي غير معتادة إذ إنها طلب يُكمِل المصافحة الثلاثية لـ INVITE بدل أن يتوقّع استجابته الخاصة. وتُنهي BYE جلسة قائمة. وتُجهِض CANCEL عملية INVITE لم تتلقَّ استجابة نهائية بعد (مكالمة ما زالت ترنّ). وتخبر REGISTER المسجّل حيث يكون المستخدم قابلًا للوصول. وتستعلم OPTIONS عن قدرات ند وتُعاد استخدامها على نطاق واسع كنبضة إبقاء حياة خفيفة.
| الطريقة | الغرض | ملاحظة |
|---|---|---|
| INVITE | بدء جلسة | يحمل عرض SDP؛ وينشئ حوارًا (dialog) |
| ACK | تأكيد الاستجابة النهائية لطلب INVITE | يُكمل مصافحة INVITE الثلاثية |
| BYE | إنهاء جلسة قائمة | يرسله أي من الطرفين ضمن الحوار (dialog) |
| CANCEL | إلغاء طلب INVITE معلّق | فقط قبل الاستجابة النهائية (ما زال يرنّ) |
| REGISTER | تسجيل موقع Contact للمستخدم | يُجدَّد دوريًا (Expires) |
| OPTIONS | الاستعلام عن القدرات | يُعاد استخدامها عادةً كـ keepalive / فحص سلامة |
لماذا ACK وCANCEL خاصتان
طريقتان أساسيتان تتصرّفان خلاف الباقي. ليست ACK زوج طلب/استجابة عاديًا: تُقرّ الاستجابة النهائية لـ INVITE ولا تحمل استجابة خاصة بها. ولاستجابة 2xx تُرسَل من الطرف إلى الطرف كمعاملة منفصلة؛ ولفشل غير 2xx تُولَّد قفزةً بقفزة ضمن معاملة INVITE. ولا معنى لـ CANCEL إلا ما دامت INVITE معلَّقة — وحالما تصل استجابة نهائية، استخدم BYE بدلًا منها. وإتقان هاتين الطريقتين هو لبّ آلة حالات SIP الصحيحة.
طرق الامتداد الشائعة
خارج الطرق الست الأساسية، تتولى مجموعة من طرق الامتداد الرسائل والأحداث والتحديثات أثناء المكالمة. تنفّذ SUBSCRIBE/NOTIFY إطار الأحداث (الحضور، مؤشّر انتظار الرسائل، حالة الحوار). وتُطلِق REFER تحويل المكالمة. وتحمل MESSAGE الرسائل الفورية / SMS-فوق-SIP. وتعدّل UPDATE جلسة قبل اكتمال إنشائها (الوسائط المبكّرة). وتُقرّ PRACK الاستجابات المؤقتة بموثوقية. وتحمل INFO معلومات أثناء الجلسة مثل DTMF. وتقدّم PUBLISH حالة حدث إلى خادم.
| الطريقة | RFC | الغرض |
|---|---|---|
| INFO | RFC 6086 | معلومات منتصف الجلسة (مثل أرقام DTMF) |
| PRACK | RFC 3262 | تأكيد موثوق للردود المؤقتة (1xx) |
| UPDATE | RFC 3311 | تعديل جلسة قبل الرد النهائي (الوسائط المبكرة) |
| SUBSCRIBE / NOTIFY | RFC 6665 | الاشتراك في الأحداث والإشعار بها (الحضور، MWI) |
| REFER | RFC 3515 | طلب التحويل إلى طرف آخر |
| MESSAGE | RFC 3428 | الرسائل الفورية / المراسلة بنمط الصفحة (page-mode) |
| PUBLISH | RFC 3903 | إرسال حالة الحدث (مثل حالة التواجد) إلى الخادم |
سطر طلب على السلك
يبدأ طلب SIP بسطر طلب: الطريقة، وRequest-URI (الوجهة الحالية)، وإصدار SIP. تتبعه الترويسات وجسم اختياري. والمثال بداية INVITE نحو مُستدعى؛ ويعيد الوسطاء كتابة Request-URI بينما يُوجَّه الطلب، وتبقى ترويسة To ثابتة كالهدف المنطقي.
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP host.example.net;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=1928301774
Call-ID: a84b4c76e66710@host.example.net
CSeq: 314159 INVITE
Contact: <sip:alice@host.example.net>
Content-Type: application/sdp
Content-Length: 142الأسئلة المتكررة
ما طرق SIP الست الأساسية؟
INVITE (بدء جلسة)، وACK (تأكيد استجابة INVITE نهائية)، وBYE (إنهاء جلسة)، وCANCEL (إلغاء INVITE معلَّقة)، وREGISTER (تسجيل موقع مستخدم)، وOPTIONS (الاستعلام عن القدرات). وهذه محدَّدة في RFC 3261؛ وكل ما عداها امتداد.
ما الفرق بين CANCEL وBYE؟
تُجهِض CANCEL عملية INVITE لم تتلقَّ استجابة نهائية بعد — مكالمة ما زالت ترنّ. وتُنهي BYE جلسة قائمة سلفًا. استخدم CANCEL قبل الرد وBYE بعده؛ واستخدام الخاطئة يترك آلة الحالات غير متسقة.
لماذا لا تحصل ACK على استجابة؟
توجد ACK لإقرار الاستجابة النهائية لـ INVITE وإكمال المصافحة الثلاثية، فعُرِّفت بألا تحصل على استجابة خاصة بها. ولاستجابة 2xx فهي معاملة منفصلة من الطرف إلى الطرف؛ ولفشل تُولَّد قفزةً بقفزة داخل معاملة INVITE.
كيف تُرسَل نغمات DTMF في SIP؟
أشيعها كرزم حدث هاتفي RTP (RFC 4733) في تدفق الوسائط، وبديلًا عبر رسائل SIP INFO تحمل الأرقام في مسار الإشارات. ويُفضَّل حدث RTP الهاتفي لأنه يبقى متزامنًا مع الصوت.
أي طريقة تحوّل مكالمة؟
REFER (RFC 3515). تطلب من المستلِم بدء طلب جديد (عادةً INVITE) إلى طرف ثالث مسمًّى في ترويسة Refer-To، منفّذةً تحويل المكالمة. ثم تبلّغ رسائل NOTIFY عن تقدّم المكالمة المُحالة إلى المحوِّل.
مواصفات المصدر
تستند هذه الصفحة إلى المعايير المنشورة. يفتح في علامة تبويب جديدة.