مكالمة SIP الأساسية مصافحة INVITE/200/ACK ثلاثية تتبعها وسائط وBYE. يرسل المتصل INVITE (مع عرض SDP)؛ ويردّ المُستدعى بـ 100 Trying و180 Ringing ثم 200 OK (مع إجابة SDP)؛ ويرسل المتصل ACK؛ وتتدفّق وسائط RTP؛ وينهي أي من الطرفين المكالمة بـ BYE، يُجاب بـ 200 OK.
إعداد المكالمة
تبدأ المكالمة بإرسال UAC للمتصل عملية INVITE نحو المُستدعى، حاملةً عرض SDP يصف الوسائط التي يريدها. وبينما يعبر الطلب الوسطاء، قد يعيد كل منهم 100 Trying لإيقاف إعادات الإرسال. وحين يبدأ هاتف المُستدعى بالتنبيه، تتدفّق 180 Ringing عائدةً — وهذا ما ينتج رنين الرد. وإن لزمت وسائط مبكّرة (إعلانات شبكية، أو رنين رد من الشبكة البعيدة)، يمكن أن تفتح 183 Session Progress مع SDP مسار الوسائط قبل الرد.
الرد والمصافحة الثلاثية
حين يردّ المُستدعى، يعيد UAS الخاص به 200 OK حاملةً إجابة SDP التي تُنهي تفاوض الوسائط. ويؤكّد المتصل بـ ACK — الساق الثالثة من مصافحة INVITE — ويُنشأ الحوار الآن كاملًا، محدَّدًا بـ Call-ID إضافة إلى الوسمين. وتبادل INVITE/200/ACK الثلاثي، بدل طلب/استجابة بسيط، هو ما يجعل إعداد مكالمة SIP موثوقًا حتى فوق UDP كثير الفقد.
Alice (UAC) Bob (UAS)
│ INVITE (SDP offer) ─────────▶ │
│ ◀───────── 100 Trying │
│ ◀───────── 180 Ringing │ (Bob's phone rings)
│ ◀───────── 200 OK (SDP answer) │ (Bob answers)
│ ACK ─────────▶ │
│ ◀═══════ RTP media (both ways) ═▶ │ (the conversation)
│ BYE ─────────▶ │ (Alice hangs up)
│ ◀───────── 200 OK │الوسائط والتغييرات أثناء المكالمة
حالما تُكمِل ACK الإعداد، تتدفّق وسائط RTP مباشرة بين الطرفين (أو عبر مُرحّل وسائط) على المنافذ التي تفاوضت عليها SDP، مستقلةً عن مسار الإشارات. وتُجرى التغييرات أثناء المكالمة بـ re-INVITE أو UPDATE يحمل SDP جديدًا — وهكذا يُنفَّذ التعليق (a=sendonly) والاستئناف (a=sendrecv) وإعادة تفاوض الترميز وإضافة الفيديو، جميعها ضمن الحوار القائم دون إسقاط المكالمة.
إنهاء المكالمة — BYE
ينهي أي من الطرفين مكالمة قائمة بإرسال BYE، يؤكّدها الآخر بـ 200 OK؛ ثم يُغلَق الحوار وتتوقف الوسائط. وBYE طلب داخل الحوار، فتحمل Call-ID ووسم From ووسم To القائمة وCSeq التالي. ولأنها معاملة عادية، تُعاد BYE المفقودة حتى تُقَرّ، فيتقارب الطرفان على انتهاء المكالمة.
إلغاء مكالمة قيد الإنشاء — CANCEL
إن استسلم المتصل قبل أن يردّ المُستدعى — والمكالمة ما زالت ترنّ — يرسل UAC عملية CANCEL لا BYE، لأنه لم تصل استجابة نهائية بعد. يتوقف المُستدعى عن التنبيه ويعيد 487 Request Terminated لعملية INVITE الأصلية، التي يُقرّها المتصل. وCANCEL صالحة فقط في هذه النافذة قبل الرد؛ وحالما تُستقبَل 200 OK، تُنشأ المكالمة وتكون BYE هي طريقة إنهائها.
| الحالة | الطريقة | النتيجة |
|---|---|---|
| تم الرد على المكالمة، الآن أغلق الخط | BYE | 200 OK؛ تم إغلاق الحوار |
| ما زال يرنّ، والمتصل ينهي المحاولة | CANCEL | 487 Request Terminated على طلب INVITE |
| يرفض المتصل به أثناء الرنين | (الاستجابة) 486/603 | Busy Here / Decline؛ المتصل يرسل ACK |
الأسئلة المتكررة
ما مخطط مكالمة SIP الأساسي؟
INVITE (مع عرض SDP) ← 100 Trying ← 180 Ringing ← 200 OK (مع إجابة SDP) ← ACK، ثم تتدفّق وسائط RTP، وتنتهي المكالمة بـ BYE ← 200 OK. ومصافحة INVITE/200/ACK الثلاثية تُنشئ الحوار؛ وBYE تفكّكه.
لماذا يستخدم SIP مصافحة ثلاثية لـ INVITE؟
تؤكّد ACK أن المتصل استقبل 200 OK النهائية، ما يجعل إعداد المكالمة موثوقًا حتى فوق UDP كثير الفقد. ولأن 200 OK لـ INVITE تُعاد حتى تُقَرّ بـ ACK، يضمن التبادل الثلاثي اتفاق الطرفين على قيام المكالمة قبل الوثوق بالوسائط.
كيف أعلّق مكالمة SIP؟
أرسِل re-INVITE (أو UPDATE) ضمن الحوار القائم يحمل SDP جديدًا يضبط اتجاه الوسائط إلى a=sendonly (وa=sendrecv للاستئناف). يبقى الحوار والمكالمة قائمين؛ ويتغيّر فقط اتجاه الوسائط، وهو أيضًا كيف تُسلَّم موسيقى الانتظار.
متى أرسل CANCEL بدل BYE؟
أرسِل CANCEL حين تكون المكالمة ما زالت ترنّ ولم تصل استجابة نهائية — تُجهِض INVITE المعلَّقة وتُنتج 487. وأرسِل BYE فقط بعد إنشاء المكالمة (استُقبِلت 200 OK). واستخدام الخاطئة يترك الطرفين غير متزامنين.
هل تتبع الوسائط مسار رسائل SIP نفسه؟
عادةً لا. قد تعبر إشارات SIP عدة وسطاء، لكن وسائط RTP تتدفّق على منافذ مُتفاوَض عليها منفصلةً، عادةً مباشرة بين الطرفين أو عبر مُرحّل وسائط أو SBC مخصّص — ولهذا قد تنجح الإشارات بينما يفشل الصوت مستقلًا.
مواصفات المصدر
تستند هذه الصفحة إلى المعايير المنشورة. يفتح في علامة تبويب جديدة.