أستكشاف المشكلات الأكثر شيوعا المتعلقة باستدعاءات العمل عبر Expressway وإصلاحها
المحتويات
المقدمة
يصف هذا المستند أكثر المشاكل شيوعا في نشر من أعمال إلى أعمال (B2B). كيفية أستكشاف أخطاء B2B وإصلاحها عبر طرق Expressway.
المتطلبات الأساسية
المتطلبات
توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:
- Expressway-C (EXP-C)
- Expressway-E
- برنامج Unified Call Manager (CUCM) من Cisco
- Cisco TelePresence Video Communication Server-C (VCS-C)
المكونات المستخدمة
تستند المعلومات الواردة في هذا المستند إلى إصدارات البرامج والمكونات المادية التالية:
- Expressway C و E x8.1.1 أو إصدار أحدث
- Unified Communications Manager (CUCM) 10.0 أو إصدار أحدث.
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
المشكلات الشائعة
1. خطأ //SIP/SIPTcp/wait_sdlReadRsp: تجاهل الرسالة الكبيرة. السماح فقط بما يصل إلى 5000 بايت. إعادة تعيين الاتصال.
فشل الاستدعاءات من نقاط النهاية لنظام TelePresence المسجلة إلى VCS، الواردة على خط اتصال بروتوكول بدء جلسة العمل (SIP) إلى CUCM، باستخدام "//SIP/SIPTcp/wait_SdlReadRsp: تجاهل الرسالة الكبيرة. السماح فقط بما يصل إلى 5000 بايت. إعادة تعيين الاتصال.
تكوين توجيه المكالمات في Expressway-C/VCS-C صحيح ويتم إرسال المكالمة إلى CUCM. يتم إرسال رسالة دعوة SIP إلى CUCM، ولكن في سجلات SDL لا توجد رسائل SIP. يمكن ملاحظة هذا الخطأ في سجلات SDL:
"|AppInfo |SIPTcp - تجاهل الرسالة الكبيرة من xxx.xxx.xxx.xxx:[27469]. السماح فقط بما يصل إلى 5000 بايت. إعادة تعيين الاتصال.
في CUCM 8.6 وأقل من القيمة الافتراضية لحجم رسالة SIP Max الواردة كانت 5000، بعد تغيير CUCM 9.x إلى 11000. ومع ذلك، ستحتفظ الترقية من 8 أو أقل إلى الإصدار 9 أو 10 بالقيمة الافتراضية في الإصدار السابق من البرنامج (5000).
الحل
هذه المشكلة متعلقة بالخطأ CSCts00642
قم بزيادة الحد الأقصى لحجم الرسائل الواردة لمعلمة الخدمة المتقدمة ل CUCM من القيمة الافتراضية 5000 إلى حجم مناسب لهذه الأنواع من المكالمات. يبدو أن الطراز 11000 يمثل قيمة جيدة لمعظم سيناريوهات العملاء المتوقعة.
من صفحة إدارة CUCM، انتقل إلى معلمات الخدمة وحدد خادم CUCM و خدمة CallManager:
حدد في خيار متقدم وابحث عن الحد الأقصى لحجم رسالة SIP الواردة:
2. تتوقف تدفقات الوسائط إذا قام خادم اتصال آخر بنقل المكالمة.
يمكن أن يحدث ذلك في مكالمات Mobile و Remote Access (MRA) و B2B.
قد لا يتسبب في إصدار صوت بطريقة واحدة أو في إحداث ضوضاء (نفس الضوضاء عند محاولة تشغيل التقاط باستخدام صوت مشفر) بعد نقل المكالمة. يحدث هذا لأنه يتم تحديد مجموعة تشفير في إعداد الاستدعاء غير مدعوم من قبل نقطة النهاية التي يتم الانتقال إليها.
يمكنك مقارنة تفاوض SIP قبل نقل المكالمة وبعدها. في التفاوض الأول في سجلات VCS أو CUCM، يمكنك رؤية خطوط التشفير في رسالة 200 OK من VCS:
m=audio 54582 RTP/SAVP 9 96 97 0 8 18 101 a=rtpmap:9 G722/8000 a=rtpmap:96 G7221/16000 a=fmtp:96 bitrate=32000 a=rtpmap:97 G7221/16000 a=fmtp:97 bitrate=24000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:ckXijkT3CcVY+xlOf3ozX/TjHPz05OzEdY49rAHA|2^48 a=sendrecv a=rtcp:54583 IN IP4 10.1.201.7 m=video 54658 RTP/SAVP 96 97 b=TIAS:4000000 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42e01e;max-fs=1621;packetization-mode=1;max-rcmd-nalu-size=32000;level-asymmetry-allowed=1 a=rtpmap:97 H264/90000 a=fmtp:97 profile-level-id=42e01e;max-fs=1621;packetization-mode=0;level-asymmetry-allowed=1 a=rtcp-fb:* nack pli a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:S8BJvGB/2l6F7XP8izXxId443Xd9f27oUI/4gxSt|2^48
يتم قبول خطوط التشفير في المكالمة الأولى، ولكن في المكالمة الثانية ترى أن رسالة ACK تزيل خطوط التشفير:
m=audio 24826 RTP/AVP 0 c=IN IP4 10.1.231.30 a=ptime:20 a=rtpmap:0 PCMU/8000 m=video 0 RTP/AVP 126 c=IN IP4 10.1.98.80 b=TIAS:448000 a=label:11 a=rtpmap:126 H264/90000 a=fmtp:126 profile-level-id=42E01F;packetization-mode=1;max-fs=3601;max-rcmd-nalu-size=32000;level-asymmetry-allowed=1 a=content:main
يحاول VCS إستخدام خطوط التشفير التي تم التفاوض عليها في البداية، حتى إذا كانت نقطة النهاية التي يتم نقل المكالمة إليها لا تدعم التشفير.
الحل
هذه المشكلة متعلقة بالخطأ CSCuv11790
قم بترقية VCS/Expressway إلى x8.6.1 لإصلاح هذه المشكلة.
3. مجال المستوى الأعلى غير مكون في CUCM.
إذا لم يتم تعيين معلمة مؤسسة مجال المستوى الأعلى، فإنها تتسبب في قيام CUCM بتوجيه المكالمات الواردة إلى مجالها الخاص واستخدام أنماط مسار SIP. قد يتسبب هذا في حدوث تكرار حلقي لأنه من المرجح أن يتم إعادة الاتصال إلى Exp-C، أو قد يفشل أيضا مع "خطأ غير موجود 404".
الحل
من صفحة إدارة CUCM، انتقل إلى نظام > معلمات المؤسسة لتغيير هذا الإعداد
4. يجب أن تحتوي شهادة CUCM على سمة مصادقة العميل المطبقة.
عندما يتم تعيين اتصال آمن بين Exp-C و CUCM (TLS تحقق من تشغيل)، يتم بدء مصافحة SSL من قبل مساعد اتصال محدد يعتمد على إتجاه الاستدعاء. وهذا يعني أنه يجب أن يحتوي كلا الخادمين على مصادقة العميل والخادم في شهاداتهم. يظهر هذا الخطأ في سجلات VCS/Expressway إذا لم تكن السمة موجودة:
Line 190: 2015-05-07T07:34:01-04:00 XXXXXXXXXXXXXXXX tvcs: UTCTime="2015-05-07 11:34:01,060" Module="network.tcp" Level="DEBUG": Src-ip="10.50.47.16" Src-port="45215" Dst-ip="10.50.47.51" Dst-port="5061" Detail="TCP Connecting" Line 239: 2015-05-07T07:34:01-04:00 XXXXXXXXXXXXXXXX tvcs: UTCTime="2015-05-07 11:34:01,071" Module="network.tcp" Level="DEBUG": Src-ip="10.50.47.16" Src-port="45215" Dst-ip="10.50.47.51" Dst-port="5061" Detail="TCP Connection Established" Line 249: 2015-05-07T07:34:01-04:00 XXXXXXXXXXXXXXXX tvcs: UTCTime="2015-05-07 11:34:01,081" Module="network.tcp" Level="DEBUG": Src-ip="10.50.47.16" Src-port="45215" Dst-ip="10.50.47.51" Dst-port="5061" Detail="TCP Connection Closed" Reason="no certificate returned"
الحل
يمكن العثور على تفاصيل حول كيفية تكوين قالب باستخدام كل من سمات عميل الويب والخادم في دليل شهادة VCS
5 - مسائل العمل البيني.
واجه VCS/Expressway version X8.6.x بعض المشاكل في عملية العمل البيني.
الأخطاء المتعلقة بالمشكلة:
يمكن اكتشاف الخلل CSCuw85626 إذا قمت بفحص سجلات التشخيص من VCS/Expressway لخطوط m الفيديو التي يتم رفضها:
تظهر رسالة الخطأ هذه عندما يتم التفاوض على خطوط الوسائط في جزء أجهزة التحكم في الشبكة (TCS) لتدفق H323.
مؤشر متوسط: 1
رفض: true، الإتجاه: SDP_MEDIA_DIR_SENDRECV
النوع: فيديو / SDP_MF_AU_VID
الخلل CSCuw85715 مماثل ولكن في هذه الحالة، VCS/Expressway log سيحدد أن السبب هو dataTypeNotSupported:
2015-10-29T09:49:00+04:00 XXXXXXXXXXXXXXXX tvcs: UTCTime="2015-10-29 05:49:00,197" Module="network.h323" Level="INFO": Action="Sent" Dst-ip="XXXXXXXXXXXXXXXX" Dst-port="49162"
Detail="Sending H.245 OpenLogicalChannelRejResponse "
2015-10-29T09:49:00+04:00 XXXXXXXXXXXXXXXX tvcs: UTCTime="2015-10-29 05:49:00,197" Module="network.h323" Level="DEBUG": Dst-ip="XXXXXXXXXXXXXXXX" Dst-port="49162"
Sending H.245 PDU:
value MultimediaSystemControlMessage ::= response : openLogicalChannelReject :
{
forwardLogicalChannelNumber 3,
cause dataTypeNotSupported : NULL
}
الحل
قم بالترقية إلى الإصدار X8. 7 أو إصدار أحدث.
6. لا يتم إرسال رسالة ACK المستلمة من CUCM إلى VCS-E/Expressway-E.
ويتبين ذلك عادة عندما لا تشير منطقة العبور التي تم تكوينها إلى عنوان IP الصحيح الخاص ب VCS Expressway / Expressway-E.
في عمليات نشر بطاقة واجهة الشبكة (NIC) الأحادية (على Expressway/Edge)، تحتاج منطقة العميل المتقاطعة على Control/Core إلى الإشارة إلى عنوان IP العام لخادم التقاطع.
في عمليات النشر المزدوجة لبطاقة واجهة الشبكة (NIC)، يحتاج العميل التبادلي إلى عنوان IP الداخلي (عادة ما تكون بطاقة واجهة الشبكة (NIC) الداخلية هي LAN1 ولكن يمكن أن تكون LAN2) الخاص بخادم التداول. تذكر أن هذا هو عنوان IP الداخلي من الشبكة المحلية (LAN) الداخلية.
الحل
يرجى الرجوع إلى الملحق 4 من Cisco VCS Expressway و VCS Control - التكوين الأساسي للحصول على مزيد من المعلومات ومخطط لعمليات نشر الشبكة المختلفة.
7. يقوم CUCM بإسقاط جلسة TCP على المكالمات الواردة
عند إرسال المكالمات من عنصر تحكم VCS / Expressway Core، قد يرفض CUCM هذا عن طريق إسقاط جلسة TCP.
قد يحدث ذلك عندما لا يتطابق المنفذ بين المنطقة المجاورة وملف تعريف أمان خط اتصال SIP أو تم تكوينه ليكون 5060/5061.
يستخدم MRA اتصال خطي بينما يستدعي B2B إستخدام اتصال خط اتصال، CUCM له تحديد لا يسمح لاتصالات الخط والشنطة بالمرور من خلال المنفذ نفسه. ونظرا لأنه يتم تكوين MRA في الغالب تلقائيا، تحتاج عمليات نشر B2B إلى إستخدام منفذ مختلف.
الحل
للقيام بهذا الإجراء، يلزم أن يكون منفذ الوجهة الذي تم تكوينه على المنطقة المجاورة ل CUCM (على VCS-C/Expressway-C) مختلفا عن 5060/5061، وعادة ما يتم إستخدام 5065 ولكن يمكن إستخدام أخرى، ويجب أن يتطابق المنفذ الذي تم تكوينه مع المنفذ الذي تم تكوينه على ملف تعريف أمان خط اتصال SIP الذي تم تعيينه لشنطة SIP على هذا الخادم على CUCM.
من صفحة إدارة CUCM، انتقل إلى جهاز > خط الاتصال.
ملف تعريف أمان خط اتصال SIP مع المنفذ 5065.
يمكن أن يكون منفذ وجهة خط اتصال SIP 5060/5061، كما هو موضح في الصورة.
يحتاج منفذ SIP في المنطقة المجاورة من VCS/Expressway إلى مطابقة المنفذ الذي تم تكوينه في ملف تعريف أمان خط اتصال SIP، كما هو موضح في الصورة.
من صفحة إدارة Expressway، انتقل إلى تكوين>بروتوكولات > SIP
لا يتضمن VCS هذا التحديد أو لا ينطبق على هذا السيناريو، وهذا يعني أنه يمكن تكوين خط اتصال SIP نفسه مع 5060/5061.
8. يتعذر على VCS حل FQDNs بشكل صحيح أو فشل الاستعلام عن سجلات SRV.
بالنسبة لاستدعاءات B2B التي تم إنشاؤها من CUCM، يمكن تقديم مشكلة نظرا لطبيعة كيفية معالجة CUCM للمكالمات ودفعها.
عندما يتصل CUCM Forwardi بخوادم VCS، فإن CUCM يميل إلى إضافة: 5060 أو: 5061 (اعتمادا على التكوين) في نهاية URI المطلوب (أي test@lab.local > test@lab.local:5060) عندما يصل إلى الطريق السريع ويضرب قاعدة بحث باتجاه منطقة DNS، فإن VCS لا يلفق سجل SRV، بل إنه فقط غريب لسجلات A أو AAA. يمكنك تأكيد ذلك في سجلات التشخيص من VCS/Expressway.
الحل
لحل هذه المشكلة، ببساطة قم بإنشاء تحويل يزيل المنفذ في النهاية (على أي من الخادمين، لا يهم حقا) قبل أن يصل إلى منطقة DNS.
من صفحة إدارة Expressway، انتقل إلى تشكيل > خطة طلب > تحويل التكوين > خطة طلب > تحويل
تحويل الأمثلة:
إذا تعذر إنشاء التحويل لسبب ما، يمكن أيضا القيام به من خلال قواعد البحث ولكن يوصى بالقيام بذلك من خلال التحويلات.
من صفحة إدارة Expressway، انتقل إلى التكوين > خطة الطلب > تحويل التكوين > خطة الطلب > قواعد البحث
التعليقات