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

المقدمة

يوضح هذا المستند كيفية حل مشكلة على "عنصر الحدود الموحدة (CUBE) من Cisco" عند حدوث حالات فشل في الفاكس الصادر بسبب وجود العديد من الخطوط m من الموفر. لا يفهم CUBE خطوط M متعددة، لكن يمكن تنفيذ حل بديل على CUBE لحل المشكلة باستخدام توصيفات بروتوكول بدء جلسة العمل (SIP).

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

المتطلبات

لا توجد متطلبات خاصة لهذا المستند.

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

تستند المعلومات الواردة في هذا المستند إلى إصدارات المكونات المادية والبرامج التالية:

• خادم الفاكس
• برنامج Cisco Unified Communications Manager (CUCM)
• مكعب

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

مخطط الشبكة

يستخدم المثال الموضح في هذا المستند مخطط الشبكة هذا:

المشكلة

عندما يرسل الموفر رسالة دعوة إلى المكعب أثناء نقل الصوت إلى الفاكس، ويتضمن بروتوكول وصف الجلسة (SDP) الذي يحتوي على خطين M، كان السلوك الأصلي للمكعب هو رفض المكالمة باستخدام رسالة SIP 488 Not Accepted هنا.

بعد Cisco بق id CSCtw96549، تغير هذا تصرف. الآن، إذا أرسل الموفر SDP مع خطين m، يمر المكالمة كما هو متوقع.

فيما يلي مثال على تنسيق M-line مقبول:

m=الصوت
m=صورة

ومع ذلك، إذا قام الموفر بإرسال بروتوكول SDP بتنسيق الخط M معكوسا، فإن CUBE لا يقوم بمعالجته بشكل صحيح ويرسل بروتوكول SDP مكون بشكل غير صحيح إلى خادم الفاكس في رسالة الدعوة. لذلك تفشل جميع المكالمات.

فيما يلي مثال على تنسيق خط m غير مقبول:

m=صورة
m=الصوت

تلميح: للحصول على مزيد من التفاصيل، ارجع إلى معرف تصحيح الأخطاء من Cisco CSCue70469.

الحل

لاستكشاف أخطاء هذه المشكلة وإصلاحها، قم بإجراء مكالمة إختبار فاكس صادرة وتجميع أخطاء SIP (رسائل debug ccsip). من إخراج تصحيح الأخطاء، يمكن إجراء هذه الملاحظات:

• المكالمات الصوتية تؤسس بدون مشاكل.
  
  
• وعندما يحين الوقت لتصعيد الاتصال بالفاكس، يبدأ جانب الموفر في إجراء التحويل عند اكتشاف الديباجة V.21.
  

  ملاحظة: لا يكون ذلك إلزاميا دائما للجانب الذي يتم استدعاؤه لبدء التحويل. تتوفر لدى العديد من خوادم الفاكس إمكانية بدء التحويل، حتى ولو كانت هي المحطة الطرفية التي تنشأ منها المكالمة. ويتم القيام بذلك من خلال تضمين نغمة الاستدعاء (CNG) في حزم مؤشر T.30.

• تحتوي إعادة توجيه الدعوة للمحول على خطين للوسائط (m=) بحيث يتم وضع m=image line فوق خط m=audio، وفي هذه الحالة ينشأ الخلل الموضح في معرف تصحيح الأخطاء من Cisco CSCue70469 ويقطع المكعب الاتصال.

حاليا، لا يوجد حل لهذه المسألة على المكعب، ولكن يمكنك تغيير العوامل الخارجية من أجل حل المشكلة:

• أستخدم خط M واحد فقط لنقل الصوت إلى الفاكس.
  
  
• إستخدام المرور المستند إلى البروتوكول.
  
  
• جعل الموفر يضع الخط m=audio فوق سطر m=image.
  
  
• أستخدم خادم الفاكس لبدء عملية التحويل باستخدام CNG في حزمة مؤشر T.30.

يستغل الإصدار 10.0 من CUBE ميزة جديدة لتوصيفات SIP الواردة، حيث يتم تطبيق توصيفات SIP على رسالة SIP واردة قبل تقديمها إلى مكدس SIP ومعالجتها. الفكرة وراء إستخدام توصيفات SIP الواردة في هذا السيناريو هي إزالة خط m=audio كله بحيث يعمل CUBE مع خط صورة واحد فقط.

هنا مثال على رسالة إعادة الدعوة عندما يرغب الموفر في تصعيد المكالمة الصوتية للفاكس:

Received:
INVITE sip:025027141@192.0.2.2:5060 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnm30rd10dofho0fo9011sb0000g00.1
Call-ID: 6B6CB982-B41D11E3-898F851F-F1ADD198@192.0.2.2
From: <sip:026455288@25027100.xyz>;tag=7qapqh6u-CC-36
To: "Administrator" <sip:025027141@25027100.xyz>;tag=85A6C018-2489
CSeq: 1 INVITE
Contact: <sip:192.0.2.1:5060;transport=udp>
Max-Forwards: 69
Content-Length: 431
Content-Type: application/sdp
v=0
o=HuaweiSoftX3000 22157305 22157306 IN IP4 192.0.2.1
s=Sip Call
c=IN IP4 192.0.2.1
t=0 0
m=image 53200 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy
m=audio 53190 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=silenceSupp:off - - - -
a=ecan:fb on -
a=X-fax
================================

يمكن تطبيق تكوين ملف تعريف SIP هذا لإزالة سطر m=audio:

voice class sip-profiles 966
request REINVITE sdp-header Audio-Media modify "(.*)" "a=sendrecv"
voice service voip
sip
voice-class sip profiles 966 inbound
or 
dial-peer voice XYZ voip
voice-class sip profiles 966 inbound

يقوم ملف تعريف SIP هذا بتغيير سطر m=audio إلى a=sendrecv، والذي يعمل كخط في بروتوكول SDP غير ذي صلة. وهذا يسمح للمكعب بإرسال رسالة إعادة دعوة إلى جانب خادم الفاكس وانتظار إستجابة 200 OK.

يجب عليك أيضا معالجة جانب واحد أكثر أهمية: عندما يتم إرسال رسالة 200 موافق إلى الموفر إستجابة لإعادة الدعوة المستلمة، يجب أن تقدم كلا من الأسطر m من أجل التوافق مع RFC وضمان أن رسالة الاستجابة تحتوي على نفس عدد سمات الوسائط مثل رسالة العرض.

يمكنك تحقيق ذلك من خلال ملف تعريف SIP خارجي قياسي يتم تطبيقه على نظير الطلب الذي يشير إلى الموفر:

voice class sip-profiles 200
response 200 method re-invite sdp-header Attribute modify "t38UDPRedundancy"
 "t38UDPRedundancy\x0D\x0Am=audio 0 RTP/AVP"

وهذا يضمن معالجة إعادة توجيه الدعوة باستخدام خطوط m متعددة بشكل صحيح وأن الاستجابة إلى الموفر متوافقة مع RFC لأن "t38UDPReddundancy" يتم إستبدالها ب:

"t38UDPRedundancy"
New line ( \x0D\x0A )
m=audio 0 RTP/AVP

باختصار، أستخدم إستخدام الحلول البديلة الموضحة في هذا المستند (والتي يعتمد معظمها على الموفر) لحل مشكلة الخطوط m المتعددة. ولوحظ أيضا أنه يمكن لخادم Xmedia أيضا بدء عملية التحويل، حيث يفرض على الخادم إرسال رسالة إعادة توجيه الدعوة إلى T.38 وتجنب عرض خطوط M متعددة.