لماذا يستخدم Matter بروتوكول IPv6؟ وهل يعمل إذا لم يكن IPv6 مفعّلًا في منزلي؟
يحتاج Matter إلى IPv6 محلي، وليس بالضرورة إلى إنترنت عبر IPv6. تعرّف على موجّه حدود Thread واكتشاف الأجهزة والصلاحيات وخمس خطوات لفحص الشبكة.
اشتريتَ مقبسًا يدعم Matter، وتستعد لإضافته إلى نظام المنزل الذكي. وبينما تراجع متطلبات الشبكة، تلاحظ سطرًا يقول: يلزم IPv6.
تفتح إعدادات الموجّه، فتجد أن اتصال الإنترنت لا يبدو أنه يملك عنوان IPv6، وأن أجهزة المنزل ما زالت تستخدم عناوين مثل 192.168.x.x.
هل تحتاج إلى الاتصال بمزوّد الخدمة لمجرد تشغيل مقبس؟
غالبًا لا. يحتاج Matter إلى إمكانية الاتصال عبر IPv6 داخل الشبكة المحلية، لكنه لا يشترط أن يوفّر لك مزوّد الخدمة اتصالًا بالإنترنت عبر IPv6.
لكن هذا لا يعني أنه يمكن تعطيل IPv6 تمامًا على الشبكة المحلية. فهناك مسألتان منفصلتان: هل تستطيع أجهزة المنزل التواصل فيما بينها عبر IPv6؟ وهل تستطيع الوصول إلى الإنترنت عبر IPv6؟
هذه ليست حيلة للالتفاف على المتطلبات. فمواصفة Matter الأساسية، الإصدار 1.4.1، الصادرة عن CSA، تتناول صراحةً في قسم «طوبولوجيا الشبكة» التشغيل عندما لا يدعم مزوّد الخدمة IPv6، أو عندما تكون الشبكة مفصولة عن الإنترنت أو معزولة عنه بجدار ناري.[1]
وهنا يبرز السؤال: إذا لم يكن الاتصال بالإنترنت ضروريًا دائمًا، فلماذا يستخدم Matter بروتوكول IPv6؟ أليس IPv4 كافيًا لعدد الأجهزة الموجود في المنزل؟
المشهد الافتتاحي افتراضي. يشرح هذا المقال آليات الشبكة استنادًا إلى المواصفة ووثائق التطوير الرسمية، ولا يتضمن اختبارات عملية لتوافق الموجّهات أو الأجهزة أو الأداء عند انقطاع الإنترنت. وقد يظل تثبيت منتج معيّن أو تسجيل الدخول إلى حسابه أو استخدام وظائفه عن بُعد معتمدًا على الإنترنت.

رسم مفاهيمي مولّد بالذكاء الاصطناعي يميّز الشبكة المحلية عن الإنترنت؛ لا يمثل بنية فعلية أو اختبار اتصال.
أولًا: على Matter أن يتيح للأجهزة عبر شبكات مختلفة التحدث بلغة واحدة
تخيّل أن في منزلك ثلاثة أشياء: مقبسًا يستخدم Wi-Fi، ومستشعرًا يعمل بالبطارية ويستخدم Thread، ووحدة تحكم متصلة بكابل شبكة.
تختلف هذه الأجهزة في استهلاك الطاقة وعرض النطاق وطريقة الاتصال، ولا داعي لإجبارها جميعًا على استخدام التقنية اللاسلكية نفسها. لكن نظام التحكم يحتاج مع ذلك إلى إنجاز أمور مشتركة: العثور على الأجهزة، وقراءة حالتها، وإرسال الأوامر، والتحقق ممّن يملك حق تشغيلها.
يمكن فهم توزيع الأدوار في Matter مبدئيًا على النحو الآتي:
| الطبقة | السؤال الأساسي الذي تجيب عنه | مثال هنا |
|---|---|---|
| نموذج الأجهزة والتفاعل في Matter | ما وظائف الجهاز، وكيف تُقرأ وتُشغّل؟ | التشغيل والإيقاف، والسطوع، ودرجة الحرارة، والخصائص والأوامر المرتبطة بها |
| آليات الأمان في Matter | من يتواصل، ومن يملك حق التشغيل، وهل يمكن الوثوق بالرسائل؟ | بيانات اعتماد الهوية، والجلسات الآمنة، والتحكم في الوصول |
| شبكة IPv6 | إلى أين تُرسل البيانات، وكيف تصل عبر الشبكات؟ | الإرسال الأحادي، والإرسال متعدد الوجهات، والتوجيه عند الحاجة |
| تقنيات الشبكة الأساسية | عبر أي وصلة تُنقل البيانات فعليًا؟ | Wi-Fi، والإيثرنت، وThread |
هذا توضيح للمسؤوليات، وليس وصفًا كاملًا لمكدس البروتوكولات.
لم يخترع Matter نظام عناوين وتوجيه خاصًا بالمقابس الذكية، بل بنى تفاعلات أجهزته على شبكات IP.
تصنّف فصول البنية في مواصفة CSA بروتوكول Matter صراحةً بوصفه بروتوكول اتصال للمنازل الذكية قائمًا على IPv6، وتوضح أنه يشمل شبكات Wi-Fi والإيثرنت وThread.[1] وتميّز مواد Google التمهيدية للمطوّرين أيضًا بين الاتصال التشغيلي القائم على IPv6 واستخدام BLE المحتمل أثناء إدخال الجهاز إلى الشبكة.[2]
وبذلك يمكن لطريقة الاتصال الأساسية ووظائف الجهاز العليا أن تتطورا كلٌّ على حدة: يواصل المستشعر السعي إلى خفض استهلاك الطاقة، وتواصل وحدة التحكم استخدام الكابل، من دون أن يستلزم ذلك تغيير تعريف «درجة الحرارة» بينهما.
ثانيًا: لماذا IPv6 بدلًا من الاستمرار في استخدام IPv4؟
القول إن «عناوين IPv6 أكثر» ليس خطأ، لكنه لا يفسّر جيدًا حاجة منزل فيه بضع عشرات من الأجهزة إليه.
هناك ثلاث نقاط أقرب إلى تفسير بنية Matter.
أولًا، Thread شبكة منخفضة الاستهلاك للطاقة قائمة أصلًا على IPv6.
لم يبدأ Thread بإنشاء شبكة أجهزة مختلفة تمامًا، ليُترك بعد ذلك لبوابة من الشركة المصنّعة أن تترجم كل وظيفة إلى عالم IP. فهو يوفّر بحد ذاته إمكانيات شبكة IPv6 للأجهزة منخفضة الاستهلاك للطاقة.[3]
ويمكن لشبكتي Wi-Fi والإيثرنت أيضًا نقل IPv6. وباستخدام Matter له على نحو موحّد، تستطيع عقد Matter الأصلية على هذه الوصلات المختلفة اعتماد طبقة شبكة مشتركة، ما يقلّل الحاجة إلى تحويل بروتوكولات شبكية مختلفة بينها.
ولا يعني ذلك أن الاتصال بين الشبكات يعمل تلقائيًا: فالعبور بين Thread والشبكة المنزلية المحلية لا يزال يتطلب موجّهًا حدوديًا، وإعدادًا صحيحًا للعناوين والمسارات.
ثانيًا، لا يوفّر IPv6 عنوانًا لكل جهاز فحسب، بل يوفّر أيضًا آليات شبكية للاتصال المحلي والإرسال متعدد الوجهات.
يحتاج Matter إلى مخاطبة عقدة بعينها، وقد يحتاج أيضًا إلى إرسال رسالة إلى مجموعة من العقد. وتوضح وثائق Google للمطوّرين صراحةً أن Matter يستخدم الإرسال الأحادي والإرسال متعدد الوجهات في IPv6 للوصول إلى العقد والمجموعات، على الترتيب.[4]
ويدعم IPv6 كذلك عناوين ذات نطاقات استخدام مختلفة. ويمكن أن يكون للجهاز عنوان للاتصال المحلي، من دون الحاجة إلى منح كل مستشعر عنوانًا عامًا يمكن الوصول إليه من الإنترنت.
تجدر الإشارة هنا إلى أن IPv4 يدعم أيضًا العناوين الخاصة والإرسال متعدد الوجهات. لا يصح القول إن كل ميزة في IPv6 «مستحيلة في IPv4»، ولا إن IPv6 يضمن بطبيعته وصول أوامر التحكم الجماعي. النقطة الأساسية هي أن Matter اختار أساسًا موحّدًا للاتصال عبر IPv6، ثم عرّف فوقه قواعد التفاعل والأمان الخاصة به.
ثالثًا، تتيح طبقة الشبكة الموحّدة إعادة استخدام تقنيات IP وأدواته القائمة.
يؤكد العرض التقني من Thread Group أن أجهزة Thread وWi-Fi والإيثرنت يمكنها الانضمام بوصفها أجهزة IP إلى شبكة أوسع مشتركة.[5] ويمكن للمطوّرين تشخيص مشكلات اتصال IP واكتشاف الخدمات والتوجيه، من دون إعادة تعريف بوابة على مستوى التطبيق لكل نوع من الوصلات الأساسية.
هذا شرح لفائدة معمارية، لا ادعاء بأن IPv6 أسرع بالضرورة من IPv4، ولا عرض لجميع القرارات التاريخية التي اتخذها واضعو المعيار. ويظل استهلاك الطاقة والكمون والاستقرار في المنتج النهائي معتمدًا على البيئة اللاسلكية والتنفيذ وحمل الاستخدام.
ثالثًا: غياب «IPv6 العام» يختلف كثيرًا عن غياب «IPv6 على الشبكة المحلية»
قد يتحكم مفتاح «IPv6» في واجهة الموجّه بطريقة اتصال جهة الإنترنت، وقد يؤثر أيضًا في إعدادات الشبكة المحلية. لذلك لا يكفي اسم المفتاح وحده للحكم على إمكانية استخدام Matter.
ابدأ بالفصل بين الحالات الثلاث الآتية:
| ما تراه | ما الذي يدل عليه | ما الذي لا يمكن استنتاجه منه |
|---|---|---|
| لم يخصّص مزوّد الخدمة عنوان IPv6 أو بادئة IPv6 | قد لا يتوفر اتصال بالإنترنت عبر IPv6 | لا يعني أن أجهزة المنزل عاجزة عن التواصل محليًا عبر IPv6 |
للجهاز عنوان 192.168.x.x |
للجهاز عنوان IPv4 | لا يعني أنه لا يستخدم IPv6 في الوقت نفسه |
| يظهر عنوان IPv6 على واجهة الشبكة | يوجد عنوان IPv6 واحد على الأقل | لا يعني أن الجهاز المقصود قابل للوصول، أو أن اكتشاف الخدمة يعمل، أو أن تفويض Matter قد نجح |
يمكن أن يعمل IPv4 وIPv6 معًا. وظهور عنوان IPv4 مألوف في لوحة الإعدادات لا يعني أن الجهاز يدعم IPv4 وحده.
وفي المقابل، لا يكفي ظهور عنوان محلي للوصلة يبدأ بـfe80:: للجزم بأن الاتصال يعمل في أنحاء المنزل. فهذا النوع من العناوين يُستخدم داخل الوصلة التي ينتمي إليها، ولا يستطيع الموجّه العادي تمريره إلى شبكة فرعية أخرى. وللعبور إلى Thread أو شبكة أخرى، يلزم أيضًا وجود عناوين ومسارات مناسبة للاتصال بين الشبكات.[6][7]
تقدّم وثائق Matter الرسمية لدى Home Assistant توضيحًا مباشرًا: لا يلزم اتصال بالإنترنت عبر IPv6، ولا خادم DHCPv6، لكن يجب تمكين دعم IPv6 على المضيف، وأن تمر حركة IPv6 والإرسال متعدد الوجهات ذات الصلة بصورة صحيحة.[8]
لذلك ينبغي أن يكون ترتيب التشخيص: تحقق أولًا من عمل IPv6 المحلي، ثم انظر هل يرتبط العطل فعلًا بالإنترنت.
وإذا أردت اختبار العمل دون إنترنت، فافصل اتصال الإنترنت مع إبقاء الموجّه ونقطة الوصول ووحدة التحكم والموجّه الحدودي قيد التشغيل، والحفاظ على الشبكة المحلية. أما فصل الموجّه نفسه عن الكهرباء فلا يختبر «غياب الإنترنت» وحده.
رابعًا: هل موجّه Thread الحدودي نوع آخر من «البوابات»؟
تُستخدم كلمات مثل «بوابة» و«مركز» وHub بالتبادل في صفحات المنتجات. لكن عند تصميم النظام وتشخيص أعطاله، من الأفضل التمييز بينها بحسب الوظيفة.
عند التحكم في مقبس Matter يعمل عبر Thread، قد يكون مسار الاتصال كالتالي:
وحدة تحكم Matter ← Wi-Fi/الإيثرنت ← موجّه Thread الحدودي ← شبكة Thread ← مقبس Matter.
يتحدث الطرفان بروتوكول Matter، بينما تتمثل المهمة الأساسية للموجّه الحدودي في تمرير بيانات IP عبر حدود الشبكات والمساعدة في اكتشاف الخدمات. وتسرد وثائق OpenThread الرسمية صراحةً الاتصال ثنائي الاتجاه عبر IP بين Thread وWi-Fi/الإيثرنت، إلى جانب وظائف اكتشاف الخدمات المرتبطة بـmDNS وSRP.[7]
ولا يحتاج الموجّه، لمجرد انتقال الوصلة من Wi-Fi إلى Thread، إلى ترجمة أمر Matter «شغّل الضوء» إلى أمر «شغّل الضوء» في بروتوكول تطبيق آخر.
أما إضافة جهاز غير داعم لـMatter يعمل عبر Zigbee أو Bluetooth Mesh إلى Matter فهي حالة مختلفة: إذ يجب على الجسر أيضًا أن يحوّل إمكانيات الجهاز وحالته من تلك التقنية إلى نموذج بيانات يفهمه Matter.[1][2]
| الدور | المسؤولية الأساسية |
|---|---|
| الموجّه المنزلي العادي/نقطة الوصول | توفير شبكة IP المناسبة أو التوجيه أو الاتصال عبر Wi-Fi؛ ودعمه IPv6 لا يعني أنه يدعم Thread تلقائيًا |
| موجّه Thread الحدودي | ربط Thread بشبكة IP مجاورة، وتوفير ما يلزم من دعم للتوجيه واكتشاف الخدمات |
| وحدة تحكم Matter | قراءة عقد Matter أو التحكم فيها بهوية تملك التفويض المناسب |
| جسر Matter | تمثيل إمكانيات الأجهزة العاملة بتقنيات أخرى ضمن نموذج بيانات Matter |
قد يجمع مكبّر صوت أو منتج يُسمّى «بوابة» عدة أدوار في جهاز واحد. واجتماع الأدوار في صندوق واحد لا يجعل مسؤولياتها شيئًا واحدًا.
وهناك نقطة أخرى يسهل إساءة تقديرها: إمكانية الوصول عبر الشبكة لا تعني امتلاك صلاحية التحكم. فالـFabric في Matter نطاق منطقي منظّم حول جذر ثقة مشترك، وليس اسم شبكة Wi-Fi ولا شبكة IPv6 فرعية. ويمكن أن توجد عدة شبكات Fabric على الشبكة المنزلية نفسها، بينما تحدد بيانات اعتماد Matter والتحكم في الوصول صلاحيات التشغيل.[1]
خامسًا: عثر Bluetooth على الجهاز، فلماذا قد تفشل إضافته؟
لأن «العثور على جهاز ينتظر الإضافة» و«انتقال الجهاز إلى حالة التشغيل المعتادة» خطوتان مختلفتان.
قد تبدأ بعض إجراءات الإعداد الشائعة بالعثور على الجهاز عبر BLE وإنشاء قناة إعداد أولية، ثم تهيئة شبكة Wi-Fi أو Thread. وبعد ذلك لا يزال على الجهاز الانضمام إلى شبكة التشغيل، واستكمال الاكتشاف والجلسة الآمنة والتأكيد النهائي لإضافته.[1][2]
لذلك، لا يدل ظهور الجهاز عند البحث بالهاتف إلا على نجاح تلك الخطوة من الاكتشاف؛ ولا يضمن نجاح الاتصال اللاحق عبر IPv6.
بعد انضمام الجهاز إلى الشبكة، يستخدم اكتشاف Matter أثناء التشغيل DNS-SD القائم على IP. وغالبًا ما يتضمن ذلك mDNS في الشبكات المحلية المعتادة؛ وقد يتعاون SRP ووكيل الاكتشاف على الموجّه الحدودي لتسجيل خدمات أجهزة Thread وإتاحتها للاكتشاف خارج شبكتها.[4][7][9]
عند فصل هذه المراحل، يسهل وصف العطل:
- يمكن العثور على الجهاز، لكنه لا ينضم إلى شبكة التشغيل: تحقق من بيانات اعتماد الشبكة، وطرق الاتصال التي يدعمها الجهاز، وشروط انضمامه إلى Thread.
- انضم إلى الشبكة، لكن وحدة التحكم لا تعثر عليه: تحقق من وصول معلومات اكتشاف الخدمة إلى وحدة التحكم، ومن إمكانية الوصول إلى عنوان IPv6 الذي تعيده عملية الاكتشاف.
- يمكن العثور عليه والوصول إليه عبر الشبكة، لكن التحكم يفشل: افحص جلسة Matter الآمنة وFabric وصلاحيات الوصول وتنفيذ الجهاز.
هذه اتجاهات للتشخيص، وليست أسبابًا جذرية يمكن الجزم بها من الأعراض وحدها. فلا تدع عبارة «فشل الإعداد» تخلط بين مراحل Bluetooth وشبكة IP وصلاحيات التطبيق.
سادسًا: عند حدوث مشكلة فعلية، افحص هذه الأمور الخمسة أولًا
حدّد أولًا نوع جهاز Matter الذي اشتريته. تختلف متطلبات الشبكة بين إصدار Wi-Fi وإصدار Thread. ودعم موجّه Wi-Fi العادي لـIPv6 لا يعني أنه يملك واجهة لاسلكية لـThread أو وظيفة الموجّه الحدودي.
ثم تحقق من IPv6 في البيئة التي تعمل فيها وحدة التحكم فعليًا. يستحق الأمر انتباهًا خاصًا في البوابات المطوّرة ذاتيًا والآلات الافتراضية والحاويات: فوجود عنوان IPv6 على الجهاز المضيف لا يعني أن البيئة التي تشغّل خدمة Matter تملك الاتصال الشبكي نفسه.
تحقق من عدم عزل الأجهزة بعضها عن بعض. قد تجعل شبكة الضيوف، أو عزل عملاء نقطة الوصول، أو VLAN، أو قواعد الجدار الناري، كل جهاز قادرًا على الوصول إلى الإنترنت مع عجز الأجهزة عن اكتشاف بعضها أو التواصل كما يلزم. وعند التحقق للمرة الأولى، يمكنك إنشاء حالة مرجعية على شبكة محلية موثوقة وبسيطة البنية تسمح بالتواصل، ثم إضافة سياسات العزل تدريجيًا.[8]
افحص «الاكتشاف» و«الاتصال» كلًّا على حدة. يعالج DNS-SD/mDNS العثور على الخدمة ومعلومات الاتصال بها؛ وبعد ذلك لا يزال الوصول إلى الجهاز يتطلب مسار IPv6 صحيحًا. وعند العبور بين شبكات VLAN، لا تعني إضافة مُرحّل mDNS وحده أن العناوين والمسارات والإرسال متعدد الوجهات وقواعد الوصول قد أُعدّت جميعها.
أخيرًا، ميّز بين التحكم المحلي والوظائف السحابية. فقد يعتمد IPv6 المقدّم من مزوّد الخدمة، وحساب الشركة المصنّعة، والتحكم عن بُعد، والخدمات الصوتية، وتنزيل البرامج الثابتة على متطلبات مختلفة. وقدرة Matter على التحكم المحلي لا تعني أن منتجًا معيّنًا يعمل بالكامل دون اتصال بالإنترنت، من تثبيته الأول إلى جميع وظائفه الإضافية.[8]
يُستحسن أن تسجّل في كل مرة «المرحلة التي حدث فيها الفشل، والشبكة التي يوجد عليها كل طرف، والعنوان الذي أعاده الاكتشاف، وما إذا نجح الاتصال الفعلي»، بدل الاكتفاء بعبارة «هذا الموجّه غير متوافق».
ولا داعي لتعطيل جدار الحماية في الموجّه كله لمجرد تجربة Matter. حدّد أولًا الإمكانية الناقصة أو حركة البيانات المحجوبة على مسار الاتصال المحلي، ثم عدّل الإعدادات المعنية تحديدًا.
سابعًا: استخدام IPv6 لا يعني تعريض الجهاز مباشرةً للإنترنت
تبقى فكرتان شائعتان تحتاجان إلى توضيح.
عنوان IPv6 ليس تصريحًا يتيح لأي شخص التحكم عن بُعد. فإمكانية الوصول إلى جهاز من الإنترنت تعتمد على نوع العنوان والتوجيه والجدار الناري؛ وحتى إذا أمكن الوصول إليه عبر الشبكة، تظل لدى Matter آلياتها الخاصة للمصادقة والتشفير والتحكم في الوصول.[1]
ولا يجعل IPv6 الاتصال آمنًا تلقائيًا. ينبع أمان Matter من بيانات اعتماده وجلساته وحماية رسائله وآليات صلاحياته المحددة، ومن تنفيذ المنتج وصيانته على نحو صحيح؛ ولا يمكن اختزاله في عبارة «إنه آمن لأنه يستخدم IPv6».
وبالعودة إلى المقبس في البداية: ما تحتاج إلى التحقق منه أولًا هو وجود مسار محلي بينه وبين وحدة التحكم يتيح اكتشاف الخدمة ونقل بيانات IPv6، مع توافر التفويض الصحيح.
اختار Matter بروتوكول IPv6 كي تتمكن الأجهزة ذات طرق الاتصال المختلفة من العمل على أساس شبكي موحّد. وإعداد هذا المسار المحلي إعدادًا صحيحًا أقرب إلى حل المشكلة من البدء بطلب عنوان IPv6 عام.
المصادر ونطاق التحقق
تاريخ مراجعة المصادر: 2026-11-06. يستشهد هذا المقال بمواصفة Matter 1.4.1 بوصفها إصدارًا يمكن الرجوع إليه للتحقق، ولا يصفها بأنها أحدث إصدار؛ كما لا يستنتج التوافق الكامل لجميع الأنظمة من دليل تابع لشركة واحدة.
- CSA: Matter Core Specification 1.4.1، 2025-03-17. جرت مراجعة الأقسام 2.1–2.4 و2.7–2.8 على وجه الخصوص: البنية، وطوبولوجيا الشبكة، والتشغيل دون IPv6 عام، وFabric، والأمان، وإجراءات إضافة الجهاز.
- Google Home Developers: What is Matter?. للتحقق من استخدام IPv6 في اتصال التشغيل، ودور BLE أثناء إضافة الجهاز، ومفهوم الجسر؛ مع الرجوع إلى النص الإنجليزي لتجنب لبس الترجمة الآلية.
- OpenThread: What is Thread?. للتحقق من أن Thread شبكة IPv6 موجّهة إلى الأجهزة منخفضة الاستهلاك للطاقة.
- Google Home Developers: Thread and IPv6. للتحقق من الإرسال الأحادي ومتعدد الوجهات، والتوجيه الحدودي، ووكيل الاكتشاف؛ ولا تُستخدم أرقام الإنتاجية أو الكمون في أمثلته بوصفها مؤشرات لأداء المنتجات.
- Thread Group: Multiple Thread Networks and The Seamless Interconnectivity of IP، 2023-08-24. لفهم فوائد الاتصال عبر IP بين الوصلات المختلفة؛ مع ضرورة التمييز بين إمكانية الوصول عبر الشبكة والتفويض في Matter.
- OpenThread: IPv6 Addressing. للتحقق من نطاقات استخدام العناوين وإمكانية امتلاك الجهاز الواحد عدة عناوين، من دون افتراض أن جميع عناوين Thread الداخلية قابلة للوصول عبر الشبكات.
- OpenThread: Border Router. للتحقق من التوجيه الحدودي، واكتشاف الخدمات باستخدام mDNS/SRP، وعدم تمرير العناوين المحلية للوصلة عبر الحدود.
- وثائق التكامل الرسمية لـMatter لدى Home Assistant، مع الرجوع خصوصًا إلى قسمي Introduction وGeneral recommendations. للمقارنة والتحقق من متطلبات التحكم المحلي وإعداد IPv6؛ أما خطوات التثبيت المحددة فهي خاصة بـHome Assistant ولا تُعمّم على جميع المنصات.
- Google Home Developers: Commissionable and Operational Discovery. للتحقق من الفرق بين الاكتشاف أثناء إضافة الجهاز والاكتشاف أثناء التشغيل، ومن DNS-SD ووكيل تسجيل خدمات Thread.
Discussion
Share a question or your experience. Comments appear after moderation. Your email is never displayed publicly. Comment privacy
Loading comments…