Skip to main content

دليل أول عملية port-in

دليلا التشغيل — نقل رقم من الطرف إلى الطرف والخروج الآمن برقم — يغطيان كل نقطة نهاية وكل حالة حدية. هذه الصفحة هي قائمة التحقق الأقصر للمرة الأولى التي تنقل فيها رقمًا: ترتب القرارات، وتسمّي الشيء الواحد الذي يحميه كل خطوة، وتربط عمليات النقل المتعثرة بسبب الرفض الذي تسبب فيها. اقرأها مرة واحدة ثم نفّذ عمليتك والصفحتان مفتوحتان. القراءات (check وget وtimeline) تحتاج نطاق numbers:read; والكتابات (إنشاء، رفع LOA/توقيع/إرسال، إلغاء، ضبط PIN) تحتاج numbers:write ودور owner أو admin أو developer. لا تضيف هذه الصفحة شيئا إلى الدليلين — إنها الخريطة بينهما لا البديل عنهما. ويبقيان هما المرجع الرسمي.

1. آلة الحالات التي تتنقل فيها

اتجاه نقل الرقم كلاهما آلة حالات أحادية الاتجاه. معرفة الحالة التي أنت فيها تخبرك ما الأفعال التي ما تزال مفتوحة — معظم أخطاء النقل الأول هي فعل حاولوه متأخرًا بدرجة واحدة.

Port-in (الرقم ينتقل إلى Orbit)

submitted → reviewing → approved → completed، مع rejected وcancelled كفرعين نهائيين، وsupplement_submitted كحالة انتظار بينما يزن المشغل تعديلك:
  • submitted — الطلب موجود. قابل للإلغاء (DELETE /numbers/porting/:id). علامة staging: "draft" في استجابة الإنشاء تعني أن الصف محفوظ لكن لم يُرسل شيء إلى المشغل إطلاقًا — لا تتحرك المسودة إلا بعد رفع LOA وتوقيعه.
  • reviewing — المشغل الخاسر يحتفظ بطلبك مع LOA الموقع ويفحص بيانات CSR. ما يزال قابلًا للإلغاء. ما بعد ذلك ليس كذلك.
  • approved — قبِل المشغل الخاسر وأصدر (عادة) تاريخ FOC. الإلغاء الآن يعيد 409; وستكتمل عملية النقل.
  • completed — الرقم حي على حساب Orbit الخاص بك، مرة واحدة بالضبط، مع إطلاق number.ported.
  • rejected — رفض المشغل; يحمل rejectionReason الرمز المترجم. الرفض القابل للإصلاح يفتح نافذة supplement مدتها 7 أيام; وإرسال تعديل يوقف الصف في supplement_submitted حتى يقبله المشغل (عودة إلى reviewing) أو يرفضه مجددًا.
  • cancelled — فرع نهائي لكل من port-in وport-out; لا ينطبق شيء آخر بعده.
ولدى LOA آلته الثلاثية الخاصة فوق ذلك: loaSignatureStatus: draft → signed → submitted، ولا تتقدم إلا إلى الأمام. LOA قديم التوقيع أو وثيقة خاطئة لا يمكن استبداله بعد signed — ألغِ عملية النقل وأعد الإرسال.

Port-out (الرقم ينتقل خارج Orbit)

التقدم نفسه، لكنه مقيد أولًا بحالة الرقم نفسه: released وsuspended وparked وport_out_pending كلها ترفض الإرسال بـ409، لذا فحص الحالة المسبق هو أول ما يُشغَّل. بعد تحويل FOC يملك المشغل الفائز الرقم — لا إلغاء ولا تراجع.

2. قائمة ما قبل الاستيراد — قبل أول استدعاء API

كل صنف رفض في القسم 5 يرجع إلى شيء في هذه القائمة. نفّذها قبل الإرسال لا بعده:
  1. سجل خدمة العميل (CSR) من المشغل الخاسر — الاسم القانوني للكيان ورقم الحساب ورقم هاتف الفوترة (BTN) وعنوان الخدمة وأي PIN للتحويل، منسوخة حرفيًا. لا تعد كتابتها من الذاكرة; رفضا NAME_MISMATCH وADDRESS_MISMATCH يأتيان شبه كليًا من حقول CSR مُخمَّنة.
  2. موقّع مخوّل — شخص محدد بالاسم والصفة مخوّل بنقل الرقم وسيوقّع LOA. يجب أن يطابق اسمه هنا توقيع LOA وسجلات المشغل الخاسر تمامًا.
  3. نسخة LOA — PDF حقيقي بدقة 200 dpi فأكثر، توقيع مؤرخ خلال 30 يومًا، وكل أرقام النقل مدرجة فيه. تتركّز رفضات LOA_INVALID هنا.
  4. PIN للخروج مضبوط مسبقًا على أرقامك في Orbit — قبل إدخال أرقام جديدة، احمِ التي تملكها. POST /numbers/:id/port-out-protection مع PIN بطول 4–32 محرفًا يعني أن بيانات الاعتماد وحدها لا يمكنها أبدًا إرسال port-out; وأي شيء بلا PIN مطابق يُرفض بـ401 قبل الاتصال بالمشغل. سجّل الـ PIN في مخزن أسرارك يوم ضبطه — لا مسار استرداد، فقط تدوير.
  5. معرفة قواعد البلد — أرقام الولايات المتحدة/كندا تحصل على فحص نقل مباشر متزامن; وكل ما عداها يعيد check-not-supported وتكون الأهلية يدوية. الأرقام المجانية لا تستخدم مسار LNP إطلاقًا — تنتقل بتغيير RespOrg عبر POST /numbers/porting/toll-free/resporg.
  6. قرار الأهلية في اليد — شغّل POST /numbers/porting/pre-validate واشترط ready: true. ذلك الاستدعاء الواحد يشغّل فحص النقل ويفحص حقول CSR معًا — صنفا الرفض في بوابة واحدة.
إذا بقي أي بند في القائمة بلا حسم، توقف. انضباط البوابات قبل أول إنشاء هو ما يمنع أن يتحول النقل الأول إلى رفض بعد ثلاثة أسابيع.

3. خطوة بخطوة — ترتيب المعالج

نموذج Number Porting في لوحة التحكم يمشي هذا الترتيب نفسه; والمكافئ عبر الواجهة البرمجية في الدليل. الترتيب نفسه هو ما يهم:
  1. أدخل الأرقام (رقم E.164 واحد في كل سطر) ← شغّل بوابة ما قبل الإطلاق. إما مؤهل، أو لا تتقدم.
  2. املأ حقول المشغل + CSR — المشغل الخاسر ورقم الحساب وPIN (لاسلكي الولايات المتحدة) والموقّع المخوّل وعنوان الخدمة — نسخ طبق الأصل عن CSR.
  3. نقطة توقف كمسودة — draft: true تخزن الطلب محليًا بـstaging: "draft" ولا تمس أي مشغل. إعادة الإنشاء بالمجموعة نفسها من الأرقام idempotent، فلا تشعب نقطةَ التوقف إعادةُ زيارة أو تحديث للصفحة.
  4. ارفع LOA داخل المنصة (POST /numbers/porting/:id/loa) — PDF/صورة أقل من 10MB.
  5. وقّع (.../loa/sign) — اسم الموقّع وبريده الإلكتروني وإقراره. التوقيع مرتين يعيد 422; وإذا وصلت إلى هنا مرتين فثمّة خطأ ما.
  6. أرسل (.../loa/submit) — الفعل الوحيد الصالح في حالة signed. هذه هي اللحظة التي يبدأ فيها المشغل الخاسر مراجعة تستغرق 7–14 يوم عمل.
  7. تتبّع FOC — GET /numbers/porting/:id/timeline يفرد الحالة المسطحة إلى مدخلات لكل مرحلة مع طوابع زمنية، ويعرض focDate في اللحظة التي يعين فيها المشغل واحدًا. راقب حتى status: completed.
  8. عند التحويل يُطلق number.ported مرة واحدة بالضبط — يدخل الرقم دورة الحياة العادية (تجديد تلقائي، تحرير، إعادة إسناد) كما يفعل DID مشترى. والسلوك الجهّز لـSMS على رقم منقول يطابق سلوكه على رقم مشترى.
  9. لا تُركن مسودة أبدًا — المسودة لا تبلغ المشغل ولا تحصل على FOC ولا تكتمل أبدًا. تعلّم لوحة التحكم هذه الحالة بالضبط كـ”draft — LOA pending”. إذا كان الموقّع غير متاح أو CSR غير معروف، ألغِ المسودة وأعد إنشاءها عند الجاهزية; نقطة التوقف التي تتقادم بصمت هي أكثر الطرق شيوعًا لتعطل النقل الأول بهدوء.
إذا كانت العملية في submitted أو reviewing وثمّ خطأ فيها، ألغِها بـDELETE /numbers/porting/:id. بعد approved يعيد الإلغاء 409 — ستكتمل العملية وفق جدول المشغل.

4. webhooks الحالة — بماذا تشترك

سجّل نقطة webhook واحدة واشترك في أحداث النقل بدل الاستطلاع. الأحداث التي تحرّك نقلًا أول: التسليم مرة واحدة على الأقل، لذا أزل التكرار اعتمادًا على id الحدث في مستقبلك. الأحداث تقود التحديثات اللحظية; ومسح يومي لـGET /numbers/porting + timeline يصالح ما فاتك. الكتالوج الكامل في Webhook Events; والتحقق من التوقيع في Webhook Security.

5. الرفضات الشائعة — وإصلاح كل منها

يترجم GET /numbers/porting/:id/timeline رموز رفض المشغل إلى summary + recommendedAction بلغة واضحة موسومَين بخطورة: operator_fixable (أصلح بياناتك) أو needs_carrier (على المشغل الخاسر الحل) أو fatal (الرقم لا يمكن نقله إطلاقًا). الخمسة التي تعطّل النقل الأول: أي رفض بخطورة fatal (NUMBER_NOT_PORTABLE) لا يستحق ملحقًا — على الرقم البقاء لدى المشغل الخاسر. رموز المشغل المجهولة تظهر مع نص المشغل الخام محفوظًا حتى تتمكن من التصعيد بالسبب الدقيق.

6. راقبه عبر الواجهة البرمجية — الاستدعاءات الأربعة، قابلة للتشغيل

القائمة أعلاه تسمّي نقاط النهاية; وهنا الحلقة القابلة للتنفيذ الدنيا. الاستدعاءات الأربعة نفسها بـcURL وNode.js وPython وGo وRuby وPHP، مقتصرة على ما يفعله كل منها (المرجع الكامل الذي تعكسه هذه المقتطفات هو Number Porting). استخدم مفتاح API بـnumbers:read لقراءتي check وtimeline، وnumbers:write للإنشاء.
يُطلق الـ webhook POST حدث porting.request.* لكل حركة حالة بعد ذلك — في مستقبلك، أزل التكرار اعتمادًا على id الحدث وعامل number.ported بوصفه إشارة النجاح النهائية لا فحص حالة في الخط الزمني. نقطة التوقف كمسودة في الخطوة 2 مقصودة: إذا كان LOA موقّعًا وجاهزًا أصلًا، أزل draft: true لإرسال بدفعة واحدة. وفي الحالتين يعمل تسلسل LOA — رفع، توقيع، إرسال — على الـportId المعاد ويبدأ الخط الزمني بالحركة. استدعاء check محدود بـ20 طلبًا/الدقيقة; سجّل مستقبل الـ webhook مرة واحدة ولا تعد تسجيله داخل حلقة. من هنا تتولى قائمة التحقق في القسم 3: رفع LOA ← توقيع ← إرسال، ثم تتبع.

ارفع قائمتك — CSV دفعة عبر multipart

تنقل أكثر من حفنة أرقام؟ تجاوز إنشاء كل سطر في الخطوة 2 وسلّم السجل كاملًا إلى POST /numbers/port-in/bulk-csv بصيغة multipart/form-data تحت الحقل file. احفظ القائمة كـport-in-batch.csv بهذه الأعمدة بالضبط (الترتيب لا يهم، ومطابقة الترويسة لا تميز بين الأحرف):
كل صف صالح يصبح طلب نقل خاصًا به، ويبلغ الاستجابة عن جانبي الدفعة — request_ids لقيادة تسلسل LOA لكل صف، وvalidation_errors للصفوف التي تُصلح وتُرفع مجددًا (الصفوف المكررة الجارية تُتخطى، لذا إعادة الرفع المصحح آمنة):
200
الحدود: 2 MB لكل ملف، و1000 صف لكل طلب، وميزانية معالجة 30 ثانية، وطلبان في الدقيقة لكل منظمة. اقتبس أي حقل يحتوي فاصلة (billing_address يحتاجها شبه دائمًا); وترويسة ينقصها عمود مطلوب تجهض الرفع كاملًا بـ422 وتسمّي الأعمدة الناقصة.

قدّم LOA — رفع، توقيع، إرسال

يعمل LOA على معرف النقل المعاد من الخطوة 2 (أو من كل صف دفعة) كثلاثة استدعاءات متتابعة، يحرّك كل واحد loaSignatureStatus خطوة إلى الأمام. جهّز PDF حقيقيًا بدقة 200 dpi فأكثر مع توقيع مؤرخ خلال 30 يومًا وكل أرقام النقل مدرجة — تتركّز رفضات LOA_INVALID في هذه النقاط الثلاث نفسها.
يعيد كل استدعاء طلب النقل مع LOA حالةً واحدة أبعد:
Upload — 201
Sign — 200
Submit — 200
آلة الحالات تتقدم إلى الأمام فقط: بمجرد أن يكون LOA في signed أو submitted يُرفض رفع بديل — ألغِ النقل وأعد الإرسال بالوثيقة المصححة. ومن submitted يتولى الخط الزمني في الخطوة 3 الأمر.

See Also

  • Port a number end-to-end — الدليل الذي ترسمه هذه الصفحة; كل نقطة نهاية محلولة بالترتيب.
  • Port out safely — الدليل المتناظر لنقل الأرقام خارج Orbit، يشمل حماية PIN وانضباط نافذة الإلغاء.
  • Number Porting endpoint sequence — المرجع الأقصر لكل نقطة نهاية.
  • Number Lifecycle — ما ينطبق على الرقم بعد اكتمال النقل.
  • Webhook Events — الكتالوج الكامل للأحداث.