فهم منطق توجيه المكالمات على خادم الاجتماعات

المقدمة

يصف هذا المستند منطق توجيه المكالمات لخادم الاجتماعات (CMS) من Cisco (منتج Acano سابقا) الذي يتم تقسيمه في العديد من جداول توجيه المكالمات. يغطي هذا المستند المراحل والسيناريوهات المختلفة التي يمكن أن تأخذها المكالمات من خلال جداول توجيه المكالمات هذه.

المتطلبات الأساسية

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

• مكون جسر اتصال خادم الاجتماعات من Cisco.

المكونات المستخدمة

تستند المعلومات الواردة في هذا المستند إلى Cisco Meeting Server على الإصدار 2.3.x.

تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.

ما هو منطق توجيه المكالمات الخاص بخادم الاجتماعات (CMS) من Cisco؟

يتضمن توجيه المكالمات على CMS بعض الجداول المختلفة لتوجيه المكالمات. باستخدام مخطط التدفق الذي يمكن تنزيله، يمكنك اتباع منطق توجيه المكالمات لكل مكالمة تصل إلى CMS. وهذا صحيح لكافة أنواع المكالمات: مكالمات تطبيق الاجتماعات من Cisco (CMA - العميل السميك أو WebRTC)، أو مكالمات بروتوكول بدء جلسة العمل القياسية (SIP) أو مكالمات Microsoft SIP ما لم يحدد خلاف ذلك.

ملاحظة: سيكون الاستثناء الوحيد للاستدعاءات التي تم بدؤها بواسطة CMS (إما CMS مباشرة للمكالمات الصادرة المجدولة من مجموعة إدارة TelePresence (TMS) أو إستدعاءات عميل CMA) حيث يتم تجاوز جدول إعادة توجيه المكالمات.

هذا هو ترتيب عملية توجيه الاتصال داخل CMS: 

1. جدول مطابقة المكالمات الواردة
2. جدول إعادة توجيه المكالمات الواردة
3. جدول المكالمات الصادرة

يتم شرح كل جدول بمزيد من التفاصيل لاحقا في الوثيقة، والتي تتضمن الصور التي تظهر فقط الجزء ذو الصلة من .

ملاحظة: تقوم CMS بتوجيه المكالمات فقط استنادا إلى توجيه المجال، وبالتالي استنادا إلى الجانب الأيمن (RHS) لمعرف الموارد الموحد (URI). لا توجد وظيفة توجيه المكالمات استنادا إلى الجانب الأيسر (LHS) لمعرف مواقع المعلومات (URI) كما هو الحال لديك على Cisco Unified Communications Manager (CUCM) باستخدام توجيه رقم الدليل (أنماط المسار).

ملاحظة: كل جدول هو قائمة مرتبة تم تعيينها بواسطة سمة الأولوية. الأولوية الأعلى تعني أنها تحاول أن تتطابق أولا. إذا لم تتطابق مع القاعدة التالية الموجودة في القائمة. كقاعدة عامة، امنح القواعد العامة (مثل a * التي تطابق أي مجال) أولوية أقل من القواعد الأكثر تحديدا. بهذه الطريقة، يتم التعامل مع القواعد المحددة أولا، ولديك رد محتمل للقواعد الأكثر عمومية.

الخطوة 1. جدول مطابقة المكالمات الواردة

هذه هي الخطوة الأولى في العملية التي تحدد فيها CMS ما إذا كانت المكالمة الواردة موجهة لخادم الاجتماعات من Cisco نفسه وما إذا كانت تحتاج إلى المعالجة عليها بشكل إضافي أم أنها مكالمة موجهة لنظام مختلف يكون CMS فيه هو العميل الذي يتداخل مع الاتصال ويقوم بمعالجة كل من الوسائط وإرسال الإشارات (على سبيل المثال، تستدعى عبارة Skype نقاط النهاية ل SIP القياسية أو العكس).

وهو يتحقق مما إذا كان جزء المجال من URI الوارد يطابق الجدول المطابق الوارد أم لا. إذا كان غير مطابق، يمكن توجيه المكالمة إلى مساحة أو مستخدم أو IVR أو إجراء بحث مؤتمر Lync (قيد التشغيل أو خارج الإعداد) وفقا للتكوين الخاص بك لقاعدة Dialplan هذه. لا يسمح الجدول بمجالات حرف البدل، إنه يتطلب تطابق كامل.

ملاحظة: إذا لم يكن لديك أي مجالات مطابقة مكالمات واردة تم تكوينها، فإن CMS يقبل جميع عناوين URI الواردة من SIP أو Lync الاستدعاءات التي تهبط على CallBridge. لعملاء CMA (WebRTC أو العميل السميك) على الرغم من أنها تقبل المكالمة، ومع ذلك لا يتم توجيهها إلى المساحة أو المستخدم الصحيح تلقائيا. وبالتالي، من المهم إدخال المجال الصحيح عند إستخدام عميل CMA للطلب على المسافات أو المستخدمين في هذه الحالة.

على سبيل المثال، يتم عرض جدول مطابقة المكالمات في الصورة (يظهر فقط خيار مساحات الأهداف والمستخدمين للإيجاز):

يتم إعداد المجال هنا ك acano.steven.lab الذي يطلبه العملاء عادة. ومع ذلك، فإنه يسمح أيضا باستدعاءات مخصصة أو أنماط مسار SIP معينة من CUCM (أو قواعد البحث في Expressway) التي تستهدف فقط جسر اتصال محدد (في حالة نظام المجموعة) بواسطة القاعدة الاحتياطية الأولى والثانية في الجدول الذي يطابق إما عنوان IP الخاص بجسر الاتصال (10.48.54.160 في هذه الحالة) أو اسم المجال المؤهل بالكامل (FQDN) الخاص بجسر الاتصال (acano1.acano.steven.lab في هذه الحالة).

الخطوة 2. جدول إعادة توجيه المكالمات الواردة

إذا لم يبلغ الاستدعاء أي من القواعد الموجودة في جدول مطابقة المكالمات الواردة أو لم يكن هناك تطابق لمتابعة الاستدعاء (على سبيل المثال طلب المستخدم إدخال URI غير موجود أو غير صحيح لمساحة URI)، فإنه يمر عبر الجدول الثاني الذي يسمى جدول إعادة توجيه المكالمات. وهذا أيضا يستند إلى المجال فقط ويسمح لك بحظر المكالمات على وجه التحديد إلى مجالات معينة أو للسماح فقط بالمكالمات إلى مجالات معينة. إذا كنت تريد القيام بذلك، فمن المهم أن يكون لديك قواعد أكثر تحديدا ذات أولوية أعلى، بحيث يتم فحصها أولا.

يوضح هذا المثال أن الاستدعاءات إلى dummy.com مرفوضة، بينما تتم إعادة توجيه الاستدعاءات إلى tplab.local:

عند ترك جدول إعادة توجيه الاتصال فارغا، ينتج عن ذلك حالة لا تعمل فيها CMS كبوابة بين المشاركين في Skype و SIP على سبيل المثال لعدم وجود أي قاعدة لإعادة توجيه المكالمات. بافتراض عدم تطابق مجال المكالمة الواردة في جدول مطابقة المكالمات الواردة أو تطابق المجال ولكن لا يوجد تطابق في المساحات أو المستخدمين أو عناوين IVR (أو إجتماعات Skype)، لا تتم إعادة توجيه المكالمة فيما يتعلق بجدول المكالمات الصادرة.

ملاحظة: يحدث هذا مع عملاء CMA (العملاء السميكون و WebRTC) حيث أنهم قادرون على إجراء مكالمات صادرة (*لا يمكن ل Web App في 3.0 إجراء مكالمات صادرة، ولكن بدلا من ذلك المكالمات التي تم إجراؤها بواسطة مسافة CMS بواسطة CallBridge). وعلى نحو مماثل، تعمل المكالمات الصادرة الصادرة على تدابير إدارة السلامة على نحو طيب أيضا عندما تتم عبر واجهة برمجة التطبيقات على سبيل المثال (في حالة مؤتمرات TMS المجدولة). وبشكل عام، لا يجب أن تتبع المكالمات التي يتم استهلالها من خدمة CMS نفسها (إما من خلال CMS مباشرة أو من خلال CMA) منطق إعادة توجيه المكالمات.

في سجل الأحداث، يمكنك رؤية رسالة إعادة التوجيه المميزة على سبيل المثال عندما تعمل CMS كبوابة لمكالمات SIP و Skype. وقبل ذلك مباشرة، يمكنك مشاهدة المكالمة الواردة والمكالمة الصادرة بعد ذلك.

2018-10-04  06:36:24.612  Info     call 788: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-04  06:36:24.624  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@any.com'
2018-10-04  06:36:24.625  Info     call 789: outgoing SIP call to "stejanss@any.com"

إذا لم يكن لجدول إعادة التوجيه أي قاعدة أو قاعدة رفض، فلن يظهر سجل الأحداث هذا بشكل صريح. إنه يخبرك فقط بأن إستدعاء SIP لم يتطابق (أي مساحة أو مستخدم أو IVR أو إجتماع Lync) وأنه قد تم تفويت قاعدة إعادة التوجيه (أو أنه تم تعيينها للرفض) للانتقال إلى قسم القواعد الصادرة.

2018-10-04  06:47:12.482  Info     call 790: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-04  06:47:12.495  Info     call 790: ending; local teardown, destination URI not matched - not connected after 0:00

بالنسبة لمكالمات عملاء CMA أو المكالمات الصادرة من CMS التي تم بدؤها من خلال الاجتماعات المجدولة TMS، لم تتم رؤية مكالمة واردة في سجل الأحداث. يتم توجيه المكالمة على الفور إلى جدول خطة الطلب الصادر ولا تتم معالجتها بواسطة جدول إعادة توجيه المكالمات.

في جدول إعادة توجيه المكالمات، هناك خياران آخران للتكوين: إعادة كتابة المجال ومعرف المتصل.

مجال إعادة الكتابة

يتيح لك هذا الخيار إعادة كتابة مجال المكالمة الواردة إلى مكالمة أخرى وتغيير جزء المجال من SIP Request-URI بالإضافة إلى رأس إلى رسالة SIP.

على سبيل المثال، باستخدام التكوين الموجود على هذه الصورة، يتم عرض سجل الأحداث (مع تمكين تعقب SIP) هنا لإجراء مكالمة واردة مع المجال any.com ولكن بدون تطابق في جدول مطابقة المكالمات الواردة (إما في المساحات أو المستخدمين أو IVR أو مؤتمرات Skype):

2018-10-04  07:02:24.818  Info     SIP trace: connection 0: incoming SIP TCP data from 10.48.36.215:56457 to 10.48.80.71:5060, size 1000:
2018-10-04  07:02:24.818  Info     SIP trace: INVITE sip:stejanss@any.com SIP/2.0
2018-10-04  07:02:24.818  Info     SIP trace: Via: SIP/2.0/TCP 10.48.36.215:5060;branch=z9hG4bK53e4c4ce29394
2018-10-04  07:02:24.818  Info     SIP trace: From: "EX60 Steven" <sip:1060@steven.lab>;tag=742103~ee545a46-516a-4de6-87d7-7b1f5a5b848a-26001856
2018-10-04  07:02:24.818  Info     SIP trace: To: <sip:stejanss@any.com>
..
2018-10-04  07:02:24.822  Info     call 797: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-04  07:02:24.834  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@newany.com'
2018-10-04  07:02:24.835  Info     call 798: outgoing SIP call to "stejanss@newany.com"
..
2018-10-04  07:02:24.838  Info     SIP trace: connection 19: outgoing SIP TCP data to 10.48.36.215:5060 from 10.48.80.71:57854, size 3286:
2018-10-04  07:02:24.838  Info     SIP trace: INVITE sip:stejanss@newany.com SIP/2.0
2018-10-04  07:02:24.838  Info     SIP trace: Via: SIP/2.0/TCP 10.48.80.71:5060;branch=z9hG4bKefc98b81a2961b37aee24f03c2142d8e
2018-10-04  07:02:24.839  Info     SIP trace: Call-ID: 18644f28-e998-4032-a7df-75325e9d11b0
2018-10-04  07:02:24.839  Info     SIP trace: CSeq: 659590315 INVITE
2018-10-04  07:02:24.839  Info     SIP trace: Max-Forwards: 70
2018-10-04  07:02:24.839  Info     SIP trace: Contact: <sip:1060@10.48.80.71;transport=tcp>
2018-10-04  07:02:24.839  Info     SIP trace: To: <sip:stejanss@newany.com>
2018-10-04  07:02:24.839  Info     SIP trace: From: "EX60 Steven" <sip:1060@steven.lab>;tag=2aa2a49bba231a1b

في خط الاتصال لإعادة التوجيه هذا، فإنه يعرض التعديل الذي حدث. في حالة عدم تمكين تعقب SIP، يظل هذا يظهر تعديل any.com إلى newany.com.

يأتي الاستخدام الأكثر شيوعا لعملية إعادة الكتابة هذه للمجال مع دمج Lync داخل الجهاز المسبق مع مجموعة CMS حيث يوصى بتعيين رأس جهة الاتصال ومن الرأس في القواعد الصادرة إلى Lync/Skype إلى أسماء المجالات المؤهلة بالكامل (FQDN) المحددة ل CallBridge. وهذا بسبب قواعد التوجيه التالية:

• يرسل Skype حركات جديدة ضمن مربع حوار (مثل ACK بعد دعوة - 200 OK) إلى رأس جهة الاتصال المحدد في 200 OK الذي تم إستلامه من CMS. بالنسبة للاتصالات الواردة من Skype إلى CMS، يرسل Skype أولا رسالة SIP Negotiate تحتوي على رأس MS-FE في رأس "إلى" الذي يحدد كيفية ملء رأس جهة الاتصال في ردود 200 OK على الدعوة (نظرا لأنه يستخدم نفس قناة TCP)
• يرسل Skype حوارات جديدة (مثل مشاركة المحتوى، حيث أنها مكالمة منفصلة، أو رد اتصال في حالة عدم وجود مكالمة) إلى رأس من الدعوة الأصلية

بينما يقوم بإعادة كتابة المجال، فإنه ذو صلة باستدعاء مكالمات Lync. يشير عنوان "من" الخاص ب "الدعوة الفائتة" إلى CallBridge المحدد الذي تأتي منه المكالمة. بعد ذلك يرسل Lync طلبا جديدا (INVITE) مع URI لطلب SIP الذي يطابق FQDN callBridge. ثم تتم ترجمته إلى مجال SIP من خلال قواعد إعادة الكتابة هذه. بمجرد إعادة توجيه المكالمة، فإنها تستخدم قواعد الصادر تجاه CUCM أو Expressway-C حيث تكون نقطة نهاية SIP مسجلة.

معرف المتصل

هناك خياران هنا يمكن ضبطهما على قواعد إعادة التوجيه. إما أنه تم تعيينه للتمرير ثم لم يتم إجراء أي تعديل على رأس "من" الخاص ب "الدعوات الصادرة" أو أنه تم تعيينه لاستخدام خطة الطلب التي تسمح للنظام بتعديل رأس "من" وفقا لقواعد الصادر. هذا الإعداد بغض النظر عن حقيقة ما إذا كان لديك إعادة كتابة للمجال لأن ذلك يتعلق فقط ب URI طلب SIP بالإضافة إلى رأس "إلى" الخاص ب "الدعوة الصادرة".

على سبيل المثال، تم إجراء نفس الاستدعاء السابق ولكن يوجد الآن قاعدة خطة طلب صادرة إلى newany.com (كما هو الحال بعد إعادة الكتابة في جدول إعادة توجيه المكالمات الواردة) التي تم إعدادها كمكالمة نوع Lync (ms-Conversation-ID كرأس SIP إضافي على سبيل المثال). وعلى نحو مناسب، يتم ملء Local From Domain (و Local Contact Domain) للإشارة إلى FQDN CallBridge كما هو موضح سابقا لمكالمات Lync. يعكس هذا بعد ذلك التغيير في رأس من جهة الاتصال ودعوة SIP الصادرة. كما هو موضح في الصورة، يتم تعبئتها بنفس القيمة ويمكن تحديدها بشكل فردي حسب متطلباتك.

2018-10-12  09:09:24.488  Info     SIP trace: connection 28: incoming SIP TCP data from 10.48.36.215:44460 to 10.48.80.71:5060, size 1000:
2018-10-12  09:09:24.489  Info     SIP trace: INVITE sip:stejanss@any.com SIP/2.0
2018-10-12  09:09:24.489  Info     SIP trace: Via: SIP/2.0/TCP 10.48.36.215:5060;branch=z9hG4bKf4a230ec178e
2018-10-12  09:09:24.489  Info     SIP trace: From: "EX60 Steven" <sip:1060@steven.lab>;tag=118288~ee545a46-516a-4de6-87d7-7b1f5a5b848a-32900729
2018-10-12  09:09:24.489  Info     SIP trace: To: <sip:stejanss@any.com>
2018-10-12  09:09:24.489  Info     SIP trace: Call-ID: 81e67f80-bc0164c4-f2c6-d724300a@10.48.36.215

2018-10-12  09:09:24.494  Info     call 803: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-12  09:09:24.506  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@newany.com'
2018-10-12  09:09:24.507  Info     call 804: outgoing SIP call to "stejanss@newany.com" (Lync)

2018-10-12  09:09:24.507  Info     SIP trace: connection 33: allocated for outgoing connection to 10.48.36.46:5060
2018-10-12  09:09:24.508  Info     SIP trace: connection 33: outgoing connection successful, 10.48.80.71:39782 to 10.48.36.46:5060
2018-10-12  09:09:24.510  Info     SIP trace: connection 33: outgoing SIP TCP data to 10.48.36.46:5060 from 10.48.80.71:39782, size 2971:
2018-10-12  09:09:24.510  Info     SIP trace: INVITE sip:stejanss@newany.com SIP/2.0
2018-10-12  09:09:24.510  Info     SIP trace: Via: SIP/2.0/TCP 10.48.80.71:5060;branch=z9hG4bK15bdde97ab641b586f162187cfdd98b5
2018-10-12  09:09:24.510  Info     SIP trace: Call-ID: c366ddaf-e602-4fa5-b1d6-2e16ec08534a
2018-10-12  09:09:24.510  Info     SIP trace: CSeq: 1498747095 INVITE
2018-10-12  09:09:24.510  Info     SIP trace: Max-Forwards: 70
2018-10-12  09:09:24.510  Info     SIP trace: Contact: <sip:1060@callbridgefqdn.any.com;transport=tcp>
2018-10-12  09:09:24.510  Info     SIP trace: Ms-Conversation-ID: 3P5Hu8grR1GGDF1BSMZAmw==
2018-10-12  09:09:24.510  Info     SIP trace: To: <sip:stejanss@newany.com>
2018-10-12  09:09:24.510  Info     SIP trace: From: "EX60 Steven" <sip:1060@callbridgefqdn.any.com>;tag=fb4ae780677e9d9b

في حالة تعيين قاعدة إعادة التوجيه عند المرور فقط، فلن يكون هناك أي تعديل على رأس "من" كما هو موضح كذلك من المثال السابق (في هذه الحالة تم تعيين تمرير على قاعدة إعادة التوجيه). يتم دائما تكييف رأس جهة الاتصال مع بدء CMS في إجراء اتصال جديد وبالتالي يجب إضافته في رأس جهة اتصال إلى نفسه.

يمكن إستخدام مجموعات مختلفة من معرف المتصل ومجال جهة الاتصال المحلية ومحلي من المجال. يتم إنشاء رأس From على دعوة SIP الصادرة كما هو موضح في الجدول حيث تدخل المكالمة الواردة إلى CMS مع رأس From الخاص ب usera@from.com.

الخطوة 3. جدول المكالمات الصادرة

هذا هو الجدول الأخير في منطق توجيه المكالمات الذي يقوم باستدعاء خادم مختلف ك:

• لم تتم معالجة المكالمة الواردة محليا (في مجال مطابقة المكالمات الواردة).
• إنه مكالمة صادرة من مساحة CMS (عبر CMA أو عبر واجهة برمجة التطبيقات (API) في حالة الاجتماعات المجدولة ل TMS على سبيل المثال أو مكالمة صادرة صادرة صادرة صادرة من Cisco Meeting Manager (CMM) أو من عميل CMA.

من الصورة، يمكنك أن ترى أن المنطق سهل نسبيا. في حالة عدم وجود إدخال على الإطلاق في الجدول، فإنه لا يزال يسمح بالمكالمات الصادرة ولكنه يفترض أن خادم CMS قادر على الحل على سجلات SIP SRV (_sips._tcp / _sip._tcp / sip._udp) لذلك المجال المعين كما هو مذكور في URI الخاص بطلب SIP. إذا لم يكن الجدول فارغا، ولكن لا يوجد تطابق للمجال المطلوب ثم يتم تنفيذ نفس منطق البحث في DNS. إذا كان هناك تطابق على المجال، ثم يتبع على منطق هذه القاعدة المحددة. في هذا الصدد، إذا كنت تريد منع المكالمات الصادرة من CMA أو كما تم من خلال TMS أو CMM، يمكنك القيام بذلك بطريقتين. إما أنه لا توجد أي سجلات DNS SRV (أو لا يمكن حلها بواسطة CMS) أو قم بتوجيه هذه المكالمات إلى التحكم في المكالمات (CUCM أو Expressway على سبيل المثال) وقم بحظر المكالمات هناك.

تعرض الصورة جدول إستدعاء الصادر كمثال:

باستخدام قاعدة <match all domains>عامة في النهاية والقاعدة الأولى إلى مجال Steven.lab بدون وكيل SIP لاستخدام ممتلئ (لذلك يعتمد على سجلات DNS SRV له).

لاحظ أن هذه قائمة مرتبة ذات قيمة أولوية أعلى تتم تغطيتها أولا. في حالة مطابقة قاعدة مع السلوك الذي تم تعيينه إلى "إيقاف"، لا تنتقل الاستدعاء عبر باقي الجدول بعد ذلك التطابق وفشل الاستدعاء في حالة فشل وكيل SIP هذا في توجيه الاستدعاء على سبيل المثال. عندما يتم تعيين هذا الإعداد إلى "متابعة"، يمكنك السماح بإجراء عملية إرجاع إلى مسار مختلف أو عقدة مختلفة في نظام المجموعة. على سبيل المثال، يمكنك تحديد وكيل SIP مختلف لكل قاعدة على نفس المجال. 

تمت تغطية إعدادات مجال جهة الاتصال المحلية ومحلي من المجال في القسم السابق من جدول إعادة توجيه المكالمات الواردة. يتيح لك نوع خط الاتصال تحديد نوع المكالمة التي يجب إجراؤها، والتي يمكن أن تكون SIP القياسية أو Lync أو Avaya التي تعتمد على نظام الاستلام.

يحدد حقل التشفير ما إذا كان إرسال إشارات المكالمة يجب أن يكون غير مشفر أو مشفرا. ومع ذلك، لاحظ أن هذا لا يتضمن أي تشفير للوسائط كما هو معد في تكوين تشفير وسائط SIP كما هو موجود في قائمة تكوين > إعدادات الاتصال. في هذا التكوين، لديك أيضا خيار تحديد "تلقائي" الذي يحاول إجراء المكالمة أولا باستخدام إشارات مشفرة مع إشارة إحتياطية محتملة لإرسال إشارات غير مشفرة. إذا كنت تعلم مسبقا أن الجانب الآخر مشفر أو غير مشفر، فيوصى بشدة بتعريفه وفقا لذلك لتجنب أي تأخيرات في إعداد الاستدعاء بسبب العملية الاحتياطية.

يوضح إخراج مثال لملف السجل لمكالمة إلى Steven.lab (بعد إعادة كتابة المجال على جدول إعادة توجيه المكالمات الواردة)، مع تعيين تتبع DNS وتتبع SIP على التفاصيل سجلات SRV التي يتم الاستعلام عنها وآلية التراجع في حالة تعيين التشفير على "تلقائي".

2018-10-12  11:25:16.168  Info     call 821: incoming SIP call from "sip:1060@steven.lab" to local URI "sip:stejanss@any.com"
2018-10-12  11:25:16.179  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@steven.lab'
2018-10-12  11:25:16.180  Info     call 822: outgoing SIP call to "stejanss@steven.lab"

2018-10-12  11:25:16.180  Info     DNS trace: resolving "steven.lab" (SRV "_sips._tcp", dnsType:1) for call 822
2018-10-12  11:25:16.181  Info     DNS trace: resolution of "steven.lab" (SRV "_sips._tcp") for call 822 returned result, addresses: 1
2018-10-12  11:25:16.181  Info     DNS trace: resolution of "steven.lab" (SRV "_sips._tcp") for call 822 succeeded; results: 1
2018-10-12  11:25:16.181  Info     DNS trace: resolution of "steven.lab" (SRV "_sips._tcp") for call 822 using 10.48.36.215:5061
2018-10-12  11:25:16.181  Info     SIP trace: connection 45: allocated for outgoing encrypted connection to 10.48.36.215:5061
2018-10-12  11:25:16.201  Info     handshake error 336151576 on outgoing connection 45 to 10.48.36.215:5061 from 10.48.80.71:54864
2018-10-12  11:25:16.201  Info     SIP trace: connection 45: shutting down...

2018-10-12  11:25:16.201  Info     call 822: falling back to unencrypted control connection...

2018-10-12  11:25:16.201  Info     DNS trace: resolving "steven.lab" (SRV "_sip._tcp", dnsType:1) for call 822
2018-10-12  11:25:16.202  Info     DNS trace: resolution of "steven.lab" (SRV "_sip._tcp") for call 822 returned result, addresses: 1
2018-10-12  11:25:16.202  Info     DNS trace: resolution of "steven.lab" (SRV "_sip._tcp") for call 822 succeeded; results: 1
2018-10-12  11:25:16.202  Info     DNS trace: resolution of "steven.lab" (SRV "_sip._tcp") for call 822 using 10.48.36.215:5060
2018-10-12  11:25:16.202  Info     SIP trace: connection 46: allocated for outgoing connection to 10.48.36.215:5060
2018-10-12  11:25:16.203  Info     SIP trace: connection 46: outgoing connection successful, 10.48.80.71:59776 to 10.48.36.215:5060
2018-10-12  11:25:16.205  Info     SIP trace: connection 46: outgoing SIP TCP data to 10.48.36.215:5060 from 10.48.80.71:59776, size 3290:
2018-10-12  11:25:16.205  Info     SIP trace: INVITE sip:stejanss@steven.lab SIP/2.0

ملاحظة: في حالة وجود بيئة مجمعة بها العديد من جسور الاستدعاء، يمكنك إعداد قواعد خطة اتصال صادرة لكل جسر عند تكوينها عبر واجهة برمجة تطبيقات وتحديد معرف إستدعاء (أو معرف مجموعة callbridge) لكائن واجهة برمجة التطبيقات. على سبيل المثال، افترض أنك تريد أن تخرج جميع المكالمات من اتصال واحد محدد لمجال معين (على سبيل المثال، عند الاتصال ب us.example.com، ترغب في أن يتم الخروج من الخوادم الموجودة في الولايات المتحدة). ثم تأكد من أن لديك تكوين واجهة برمجة تطبيقات (API) ل OutboundDialPlanRules حتى يتمكن كل جسر آخر من الجسر الموجود في الولايات المتحدة من توجيه المكالمة إلى CallBridge في الولايات المتحدة (في حالة هذا المثال).

OutboundDialPlanRule (ل US callBridge)

• المجال = us.example.com
• SipProxy = <blank عند إستخدام DNS SRV / IP أو FQDN إذا تم تعيينه يدويا>
• النطاق = callbridge
• CallBridge = <UScallBridge-ID>

OutboundDialPlanRules (لجميع جسور الاتصال غير الأمريكية التي يجب أن تسمح بإجراء هذه المكالمة) (تحتاج إلى واحد لكل جسر اتصال)

• المجال = us.example.com
• SipProxy = <IP-or-FQDN-of-US-CallBridge>
• النطاق = callbridge
• callbridge = <non-US-callBridge-ID>

التحقق من الصحة 

لا يوجد حاليًا إجراء للتحقق من صحة هذا التكوين.

استكشاف الأخطاء وإصلاحها 

لا توجد حاليا معلومات أستكشاف الأخطاء وإصلاحها الخاصة بهذا التكوين.

معلومات ذات صلة

• الدعم التقني والمستندات - Cisco Systems
• أداة محلل حلول التعاون 
• وثائق CMS

---

ملاحظة: للحصول على أمثلة للتكوين، يرجى مراجعة هذه الأدلة:

• تكوين دليل CMS المدمج الواحد وتكامله
• تكوين خادم الاجتماعات ودليل CUCM من Cisco