أستكشاف مشكلات الصوت أحادي الإتجاه وإصلاحها

المقدمة

يصف هذا المستند المشاكل الشائعة التي يمكن أن تحدث في محادثات الصوت أحادية الإتجاه الخاصة بهاتف IP التي تتضمن بوابات Cisco. 

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

المتطلبات

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

• شبكات IP الهاتفية ولديها معرفة أساسية بالشبكات الصوتية
• بوابات وموجهات Cisco IOS^®، ومحولات Catalyst، وعبارات DT-24+

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

لا يقتصر هذا المستند على إصدارات برامج أو أجهزة معينة.

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

الاصطلاحات

راجع اصطلاحات تلميحات Cisco التقنية للحصول على مزيد من المعلومات حول اصطلاحات المستندات.

المشكلة

يقدم هذا المستند سيناريوهات وحلول لهذه المشاكل:

• عند إنشاء مكالمة هاتفية من محطة IP من خلال بوابة الصوت أو الموجه من Cisco IOS، يتلقى واحد فقط من الأطراف الصوت (اتصال أحادي الإتجاه).

• عند إنشاء اتصال إجرائي بين بوابتين من Cisco، يتلقى طرف واحد فقط الصوت (اتصال أحادي الإتجاه).

• عند إنشاء مكالمة هاتفية من محطة IP يتم وضعها خلف عميل أجهزة VPN 3002، يتلقى طرف واحد فقط الصوت (اتصال أحادي الإتجاه).

الحلول

يمكن تنويع أسباب الصوت أحادي الإتجاه في مهاتفة IP، ولكن جذر المشكلة يتضمن عادة مشاكل توجيه IP. يلقي هذا القسم نظرة على بعض السيناريوهات والحلول التي تم العثور عليها في هذا المجال.

تأكد تمكين توجيه IP على بوابة وموجهات Cisco IOS

تقوم بعض بوابات Cisco IOS، مثل VG200، بتعطيل توجيه IP بشكل افتراضي. يؤدي هذا الإعداد الافتراضي إلى حدوث مشاكل صوتية أحادية الإتجاه.

لتمكين توجيه IP، قم بإصدار أمر التكوين العام هذا على بوابة Cisco IOS لديك:

voice-ios-gwy(config)#ip routing

التحقق من إمكانية الوصول إلى IP الأساسية

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

يمكن أن تصل الشبكتين الفرعيتان A و B إلى الشبكة الفرعية X. يمكن أن تصل الشبكة الفرعية X إلى الشبكتين الفرعيتين A و B. وهذا يسمح بإنشاء إتصالات TCP بين المحطات الطرفية (A و B) و Cisco CallManager. وبالتالي، يمكن أن تصل الإشارات إلى كلا المحطتين الطرفية دون أي مشاكل، مما يسمح بإنشاء المكالمات بين A و B.

بمجرد إنشاء مكالمة، يجب أن يتدفق تدفق تدفق تدفق RTP الذي يحمل الصوت في كلا الاتجاهين بين المحطات الطرفية. في بعض الحالات، يمكن أن تصل الشبكة الفرعية B إلى الشبكة الفرعية A، ولكن يتعذر على الشبكة الفرعية A الوصول إلى الشبكة الفرعية B. لذلك فإن تدفق الصوت من A إلى B يضيع دائما.

هذه مشكلة توجيه أساسية. أستخدم أساليب أستكشاف أخطاء توجيه IP وإصلاحها للوصول إلى المرحلة التي يمكنك فيها إختبار اتصال الهاتف A من البوابة B بنجاح. تذكر أن إختبار الاتصال هو تحقق ثنائي الإتجاه.

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

• يتم تكوين البوابات الافتراضية في المحطات الطرفية.

• تؤدي مسارات IP على هذه البوابات الافتراضية إلى شبكات الوجهة.

توضح هذه القائمة كيفية التحقق من تكوين الموجه أو البوابة الافتراضي على هواتف Cisco IP المختلفة:

• هاتف Cisco IP 7910—اضغط على الإعدادات، وحدد الخيار 6، واضغط مفتاح الصوت لأسفل إلى أن يظهر حقل الموجه الافتراضي.

• هاتف Cisco IP 7960/40—اضغط على الإعدادات، وحدد الخيار 3، وانتقل لأسفل حتى يظهر حقل الموجه الافتراضي.

• هاتف Cisco IP 2sp+/30vip-Press **#، ثم اضغط على # حتى يظهر gtwy=.

التحقق من تكوين نقطة إنهاء الوسائط الصحيح

إذا تم تكوين ترميز الشبكة لشنطة نظام مجموعة اتصال متعدد القطاعات (ICT)، فتأكد من تكوين نقطة نهاية الوسائط (MTP) في "مجموعة موارد الوسائط" وقائمة "مجموعة موارد الوسائط" المقترنة بالشنطة. إن يعين أنت MTP عندما يكون واحد غير ضروري، أو يفشل أن يشكل MTP إن يكون هو احتجت، هو معروف أن يسبب طريق واحد إصدار الصوت ل ICT تشكيل.

ربط إشارات H.323 بعنوان IP محدد على بوابة وموجهات Cisco IOS

عندما تحتوي بوابة Cisco IOS على واجهات IP متعددة نشطة، يمكن الحصول على بعض إشارات H.323 من عنوان IP واحد ويمكن لأجزاء أخرى منه الإشارة إلى عنوان مصدر مختلف. وهذا يمكن ان يولد أنواعا مختلفة من المشاكل. إحدى هذه المشاكل هي الصوت أحادي الإتجاه.

in order to التف حول هذه المشكلة، أنت يستطيع ربطت ال H.323 signaling إلى مصدر عنوان خاص. يمكن أن ينتمي عنوان المصدر إلى واجهة مادية أو افتراضية (loopback). أستخدم الأمر h323-gateway voip bind srcaddr ip-address في وضع تكوين الواجهة. قم بتكوين هذا الأمر تحت الواجهة باستخدام عنوان IP الذي يشير إليه Cisco CallManager.

تم إدخال هذا الأمر في برنامج Cisco IOS الإصدار 12.1(2)T. ارجع إلى دعم H.323 للواجهات الظاهرية.

ربط إشارات MGCP بواجهة مصدر حزمة الوسائط MGCP على بوابة Cisco IOS

يمكن أن يحدث الصوت أحادي الإتجاه في بوابات بروتوكول التحكم في عبارة الوسائط (MGCP) إذا لم يتم تحديد واجهة المصدر لإرسال الإشارات وحزم الوسائط. يمكنك ربط وسائط MGCP بواجهة المصدر إذا قمت بإصدار mgcp bind media source-interface interface-id ثم الأمر mgcp bind control source-interface interface-id erasecat4000_flash:. قم بإعادة ضبط بوابة MGCP في Cisco CallManager بعد إصدار الأوامر.

إذا لم يتم تمكين الأمر mgcp bind، فستظل طبقة IP توفر أفضل عنوان محلي.

الإرشادات الخاصة بأمر ربط mgcp هي:

• عند وجود إستدعاءات MGCP نشطة على البوابة، يتم رفض الأمر mgcp bind لكل من التحكم والوسائط.

• إذا لم تكن واجهة الربط قيد التشغيل، يتم قبول الأمر ولكنه لا يصبح نافذ المفعول حتى تظهر الواجهة.

• إذا لم يتم تعيين عنوان IP على واجهة الربط، يتم قبول الأمر mgcp bind ولكنه يسري فقط بعد تعيين عنوان IP صالح. أثناء هذا الوقت، إذا كانت إستدعاءات MGCP قيد التشغيل، يتم رفض الأمر mgcp bind.

• عندما يذهب القارن تحت، إما بسبب إيقاف عمل يدوي على القارن أو بسبب تشغيل إخفاق، الربط أعجزت نشاط على أن قارن.

• عندما لا يتم تكوين الربط على وحدة تحكم عبارة الوسائط (MGC)، يكون عنوان IP الذي يتم إستخدامه كمصدر للتحكم في MGCP والوسائط هو أفضل عنوان IP متاح.

تحقق من أن Telco أو المحول يرسل الإشراف على الإجابة ويستلم بشكل صحيح

إذا كان لديك عبارة Cisco IOS تتصل بأحد أجهزة Telco أو المحول، فتحقق من إرسال الإشراف على الإجابات بشكل صحيح عند إستجابة الجهاز المتصل خلف Telco أو المحول للمكالمة. يتسبب الفشل في تلقي الإشراف على الإجابات في فشل بوابة Cisco IOS في قطع (فتح) مسار الصوت في إتجاه إعادة توجيه. وهذا الفشل يسبب الصوت في إتجاه واحد. الحل البديل هو إصدار الأمر voice rtp send-recv on.

للحصول على مزيد من المعلومات، يمكنك الاطلاع على شق خلال الصوت ثنائي الإتجاه مبكرا باستخدام الأمر voice rtp send-recv على بوابة وموجهات Cisco IOS.

يمكنك قص الصوت ثنائي الإتجاه مبكرا باستخدام الأمر voice rtp send-recv على بوابة وموجهات Cisco IOS

يتم إنشاء مسار الصوت في الإتجاه الخلفي عند بدء تدفق RTP. لا يتم قطع مسار الصوت للأمام حتى تتلقى بوابة Cisco IOS رسالة اتصال من الطرف البعيد.

في بعض الحالات، من الضروري إنشاء مسار صوت ثنائي الإتجاه بمجرد فتح قناة RTP، والذي يكون قبل إستلام رسالة الاتصال. لتحقيق ذلك، قم بإصدار أمر التكوين العام voice rtp send-recv.

تحقق من إعدادات cRTP على أساس إرتباط-by-link على بوابة وموجهات Cisco IOS

تنطبق هذه المشكلة على السيناريوهات، مثل تجاوز الرقم الإجمالي، حيث يتم إشراك أكثر من موجه Cisco IOS أو البوابة في مسار الصوت واستخدام RTP المضغوط (cRTP). يعد cRTP، أو ضغط رأس RTP، طريقة لجعل رؤوس حزم VoIP أصغر من أجل إستعادة النطاق الترددي. يأخذ cRTP عنوان IP سعة 40 بايت أو بروتوكول مخطط بيانات المستخدم (UDP) أو رأس RTP على حزمة VoIP ويضغطه إلى 2 إلى 4 بايت لكل حزمة. ينتج عن هذا الضغط 12 كيلوبت في الثانية تقريبا من النطاق الترددي للاستدعاء المشفر G.729 باستخدام cRTP. لمزيد من المعلومات حول cRTP، ارجع إلى إستهلاك النطاق الترددي لكل اتصال عبر IP.

يتم عمل cRTP على أساس خطوة بخطوة، مع فك الضغط وإعادة الضغط على كل خطوة. يجب فحص كل رأس حزمة للتوجيه. لذلك، يلزم تمكين cRTP على كلا جانبي إرتباط IP.

ومن المهم أيضا التحقق من أن cRTP يعمل كما هو متوقع على كلا طرفي الرابط. تختلف مستويات إصدار برنامج Cisco IOS Software من حيث مسارات التحويل ودعم cRTP المتزامن.

باختصار، السيرة هي:

• في الإصدارات الأقدم من الإصدار 12.0(5)T من برنامج Cisco IOS Software، يتم تحويل العملية بواسطة cRTP.

• في برنامج Cisco IOS الإصدار 12.0(7)T، وفي برنامج Cisco IOS الإصدار 12.1(1)T، يتم تقديم دعم التحويل السريع وإعادة التوجيه السريع (CEF) من Cisco ل cRTP.

• في الإصدار 12.1(2)T من البرنامج Cisco IOS Software، يتم إدخال تحسينات على الأداء على المستوى الخوارزمي.

إذا قمت بتشغيل cRTP على الأنظمة الأساسية لبرنامج Cisco IOS (الإصدار 12.1 من برنامج Cisco IOS Software)، فتحقق من أن معرف تصحيح الأخطاء من Cisco CSCds08210 لا يؤثر على إصدار برنامج Cisco IOS الخاص بك. عرض هذا الخطأ هو فشل VoIP وإرسال الفاكس عبر IP في العمل باستخدام ضغط رأس RTP على.

يمكن فقط لمستخدمي Cisco المسجلين الوصول إلى معلومات وأدوات الأخطاء الداخلية من Cisco.

التحقق من تكوينات الساعة على بوابة Cisco IOS

إذا وجدت أن هناك انزلاقات ساعة على E1 أو T1 قارن من العرض جهاز تحكم {e1 | t1}، قد يكون هناك بعض عدم التطابق في تكوين الساعة على "بوابة الصوت". ارجع إلى تكوينات الساعة على الأنظمة الأساسية المستندة إلى IOS من Cisco والتي تدعم الصوت وتأكد من صحة تكوينات الساعة على بوابة الصوت.

دققت الحد أدنى برمجية مستوى ل nat على ال cisco ios بوابة وموجهات

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

يجب عليك تشغيل الإصدار 12.1(5)T من برنامج Cisco IOS Software أو إصدار أحدث لبوابات Cisco IOS لدعم الإصدارين Skinny و H.323 الإصدار 2 مع NAT في نفس الوقت. لمزيد من المعلومات، ارجع إلى دعم NAT لهاتف بروتوكول الإنترنت إلى Cisco CallManager.

الحد الأدنى لمستوى البرامج المطلوب لاستخدام NAT و Thin في آن واحد على جدار حماية PIX هو 6.0. لمزيد من المعلومات، ارجع إلى Cisco PIX Firewall، الإصدار 6.0.

تعطيل مسار ربط الصوت على AS5350 و AS5400

أمر برنامج Cisco IOS Software voice-fastPath enable هو أمر تكوين عام مخفي ل AS5350 و AS5400. يتم تمكين الأمر بشكل افتراضي. لتعطيله، قم بإصدار أمر التكوين العام no voice-fastPath enable.

عندما يتم تمكين الأمر، فإنه يقوم بتخزين معلومات عنوان IP ورقم منفذ UDP مؤقتا للقناة المنطقية التي يتم فتحها لمكالمة معينة. يمنع الأمر تدفق RTP من الوصول إلى طبقة التطبيق. بدلا من ذلك، تتم إعادة توجيه الحزم في طبقة أدنى. وهذا يساعد على تقليل إستخدام وحدة المعالجة المركزية (CPU) بشكل هامشي، وذلك في سيناريوهات مستوى الصوت عالية المكالمة.

عند إستخدام الخدمات التكميلية مثل الاحتجاز أو النقل، يتسبب الأمر voice-fastPath في قيام الموجه بدفق الصوت إلى عنوان IP المخزن مؤقتا ومنفذ UDP. يتم تجاهل معلومات القناة المنطقية الجديدة التي تم إنشاؤها بعد إستئناف مكالمة قيد الانتظار أو بعد اكتمال النقل. للتغلب على هذه المشكلة، يجب أن تنتقل حركة المرور إلى طبقة التطبيقات بشكل مستمر حتى يتم أخذ إعادة تعريف القناة المنطقية في الاعتبار ونقل الصوت إلى زوج منافذ IP و UDP الجديد. لذلك، تأكد من تعطيل مسار ربط الصوت لدعم الخدمات التكميلية.

شكلت ال VPN عنوان مع SoftPhone

يسمح Cisco IP SoftPhone للكمبيوتر بالعمل كهاتف سلسلة Cisco IP Phone 7900. يجب على المستخدمين البعيدين الذين يقومون بالاتصال مرة أخرى بشبكة شركتهم من خلال الشبكة الخاصة الظاهرية (VPN) تكوين بعض الإعدادات الإضافية لتجنب حدوث مشكلة صوتية أحادية الإتجاه. وذلك لأن دفق الوسائط يحتاج إلى معرفة نقطة نهاية الاتصال.

الحل هو أن يشكل ال VPN عنوان، instead of العنوان من الشبكة مهايئ، تحت الشبكة صوت عملية إعداد. أحلت ل كثير معلومة، كيف أن يستعمل cisco ip ناعم هاتف عبر VPN.

تكوين VPN 3002 للعمل في وضع امتداد الشبكة

يمكن أن يعمل عميل أجهزة Cisco VPN 3002 في وضعين: وضع العميل ووضع امتداد الشبكة (NEM). في وضع العميل، تكون جميع الأجهزة المضيفة خلف عميل Cisco VPN 3002 عنوان أيسر ترجمت إلى عنوان IP الخارجي من عميل VPN 3002. لا يعمل H.323 مع ترجمة عنوان المنفذ (PAT) وينتج عن ذلك صوت أحادي الإتجاه عندما يتم وضع هاتف IP خلف عميل VPN 3002. عندما تعمل شبكة VPN 3002 في NM، يمكن للشبكات البعيدة رؤية بعضها البعض من خلال عناوين IP الحقيقية الخاصة بها، وليس عنوان IP مستند إلى NAT أو مستند إلى PAT. إذا تم تكوين شبكة VPN 3002 للعمل في NEM، فيمكن أن يعمل H.323. بمعنى آخر، يمكن أن تعمل هواتف IP الموجودة خلف عميل VPN 3002 فقط عندما تعمل الشبكة الخاصة الظاهرية (VPN) رقم 3002 في NEM. لذلك، ومن أجل تجنب مشاكل الصوت ذات الإتجاه الواحد مع عميل VPN 3002، قم بتكوين عميل VPN 3002 لاستخدام NEM.

أخترت in order to شكلت ال cisco VPN 3002 جهاز زبون أن يستعمل NEM، تشكيل>سريع>ضرب وطقطقة لا، يستعمل شبكة امتداد أسلوب في ال ضرب نافذة.

لمزيد من المعلومات، ارجع إلى تكوين عميل جهاز Cisco VPN 3002 إلى موجه Cisco IOS مع EzVPN في وضع امتداد الشبكة

معلومات إضافية: تحقق من الصوت أحادي الإتجاه

هناك أمران مفيدان لاستخدامها للتحقق من تدفق الحزمة وهما الأمر debug cch323 rtp والأمر debug voip rtp. يعرض الأمر debug cch323 rtp الحزم التي يتم إرسالها (X) واستقبالها (R) بواسطة الموجه. يدل الحرف الكبير على نجاح الإرسال أو الاستقبال. يشير حرف صغير إلى حزمة مسقطة.

voice-ios-gwy#debug cch323 rtp

RTP packet tracing is enabled
voice-ios-gwy#
voice-ios-gwy#
voice-ios-gwy#
voice-ios-gwy#
voice-ios-gwy#

!--- This is an unanswered outgoing call. !--- Notice that the voice path only cuts through in the forward direction and 
!--- that packets are dropped. Indeed, received packets are traffic from the !--- IP phone to the PSTN phone. These are dropped until the call is answered. 
Mar 3 23:46:23.690: ****** cut through in FORWARD direction *****
XXXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr
XrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr
XrXrXXrrrrrrrrrrrrrrrr
voice-ios-gwy#
voice-ios-gwy#

!--- This is an example of an answered call:

voice-ios-gwy#
voice-ios-gwy#
*Mar 3 23:53:26.570: ****** cut through in FORWARD direction *****
XXXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr
XrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr
XXrrrrrXrXrXrXrXrXrXrXrXrXrXrXrrXXrrXrXrXrXrXrXXXXXXXXXXXXXXXXrXXXXXXXXrXrXrXXrrXr
XrXrXrXrXrXrXrXrXXrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr

!--- At this point, the remote end picks up the phone.

*Mar 3 23:53:30.378: ****** cut through in BOTH direction *****
XRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXR
XXRRXRXRXXRRXRXRXRXRXXRXRXRXRXRXRRXRXXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRXXRXRXRXRXRXRRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XXRRRRRRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXXRRRXR

!--- This is the end of the conversation.

voice-ios-gwy#debug voip rtp

--------cut through in BOTH direction-------------------

*Mar 27 19:52:08.259: RTP(32886): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFBF0, ssrc=8E5FC294
*Mar 27 19:52:08.275: RTP(247): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00C8D9, ssrc=1F1E5093
*Mar 27 19:52:08.279: RTP(32887): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFC90, ssrc=8E5FC294
*Mar 27 19:52:08.295: RTP(248): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00C979, ssrc=1F1E5093
*Mar 27 19:52:08.299: RTP(32888): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFD30, ssrc=8E5FC294
*Mar 27 19:52:08.315: RTP(249): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00CA19, ssrc=1F1E5093
*Mar 27 19:52:08.319: RTP(32889): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFDD0, ssrc=8E5FC294
*Mar 27 19:52:08.335: RTP(250): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00CAB9, ssrc=1F1E5093
*Mar 27 19:52:08.339: RTP(32890): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFE70, ssrc=8E5FC294
*Mar 27 19:52:08.355: RTP(251): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00CB59, ssrc=1F1E5093
*Mar 27 19:52:08.359: RTP(32891): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFF10, ssrc=8E5FC294
*Mar 27 19:52:08.375: RTP(252): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00CBF9, ssrc=1F1E5093
*Mar 27 19:52:08.379: RTP(32892): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFFB0, ssrc=8E5FC294
*Mar 27 19:52:08.395: RTP(253): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00CC99, ssrc=1F1E5093
*Mar 27 19:52:08.399: RTP(32893): fs rx d=10.48.79.181(20002),
pt=0, ts=500050, ssrc=8E5FC294
*Mar 27 19:52:08.976: RTP(282): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00DEB9, ssrc=1F1E5093
*Mar 27 19:52:08.980: RTP(32922): fs rx d=10.48.79.181(20002),
pt=0, ts=501270, ssrc=8E5FC294
*Mar 27 19:52:08.996: RTP(283): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00DF59, ssrc=1F1E5093
*Mar 27 19:52:09.000: RTP(32923): fs rx d=10.48.79.181(20002),
pt=0, ts=501310, ssrc=8E5FC294
*Mar 27 19:52:09.016: RTP(284): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00DFF9, ssrc=1F1E5093

تجميع معلومات حركة مرور المكالمات عبر جدار حماية PIX

يمكنك أستكشاف أخطاء المكالمات بطريقة واحدة وإصلاحها من خلال تجميع معلومات حركة مرور المكالمات عبر جدار حماية PIX. يمكن إستخدام الأمر PIX capture للتحقق من فتح المنفذ واستخدامه عند حدوث مكالمة. راجع معالجة حركة مرور VoIP باستخدام جدار حماية PIX للحصول على مزيد من المعلومات حول حركة مرور VoIP عبر جدار حماية PIX.

مشكلة الصوت أحادي الإتجاه لمدير الاتصالات الموحدة من Cisco

يمكن أن تحدث هذه المشكلة فقط في إعداد مكالمة SIP الأولية الصادرة حيث يكون MTP مطلوبا. في هذه الحالة، يمكن أن تحتوي رسالة دعوة SIP الصادرة على عرض SDP. يمكن أن تحدث المشكلة في السيناريوهات التالية:

• مكالمات خط اتصال SIP الصادرة مع نقطة إنهاء الوسائط المطلوبة التي تم فحصها على خط اتصال SIP

• المكالمات بين نقاط النهاية الخاصة ب IPv6 فقط ونقاط النهاية الخاصة ب IPv4 فقط

الحل

يمكن تسريب موارد MTP بشكل متقطع، مما يؤدي إلى فشل مكالمات SIP التي تتطلب موارد MTP. من RTMT، تصل موارد MTP المتاحة إلى 0 ويتم إجراء عمليات جرد فشل توزيع MTP لكل مكالمة تتطلب MTP. يمكن أن يحتوي جزء SDP من الدعوة الأولية بشكل غير صحيح على a=inactive.

أتمت هذا steps in order to حللت الإصدار:

1. قم بإلغاء تحديد نقطة إنهاء الوسائط المطلوبة على تكوين خط اتصال SIP، إن أمكن.

2. في حالة الحاجة إلى عرض مبكر، قم بتكوين عرض مبكر، ولكن أترك نقطة إنهاء الوسائط مطلوبة بدون تحديد.

3. لنشر IPv6، أستخدم نقاط النهاية المزدوجة بدلا من نقاط النهاية الخاصة ب IPv6 فقط.

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

• CallManager H.323: مشكلة الصوت أحادي الإتجاه بعد النقل أو الاحتجاز
• دعم NAT لهاتف بروتوكول الإنترنت إلى Cisco CallManager
• دعم H.323 للواجهات الظاهرية
• تكوين عميل أجهزة Cisco VPN 3002 إلى موجه Cisco IOS باستخدام EzVPN في وضع امتداد الشبكة
• Cisco Unity مع Cisco CallManager: One Way Audio
• تكوين بطاقات واجهة الشبكة (NIC) المزدوجة واستكشاف أخطائها وإصلاحها ل Cisco Unity
• دعم تقنية الصوت
• دعم منتجات الاتصالات الصوتية والاتصالات الموحّدة
• استكشاف أخطاء خدمة IP الهاتفية من Cisco وإصلاحها
• الدعم التقني والتنزيلات من Cisco