تكوين ترحيل DTMF على CUBE

المقدمة

يصف هذا المستند عملية تكوين ترحيل التردد المتعدد للطنين المزدوج (DTMF) لمؤسسة عنصر الحد الموحد (CUBE) من Cisco. 

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

المتطلبات

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

• معرفة أساسية لنغمات DTMF
• معرفة أساسية بكيفية تكوين صوت Cisco® IOS واستخدامه (مثل نظائر الطلب)
• معرفة أساسية بكيفية تكوين CUBE واستخدامه
• معرفة أساسية بالإشارات المستخدمة من قبل بروتوكولات SIP و H323
• معرفة أساسية بكيفية تصحيح أخطاء بروتوكولات VoIP مثل H323 و SIP

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

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

• وحدة التحكم Unified Border Element من Cisco التي تعمل على برنامج Cisco IOS.
• Cisco Unified Communications Manager، الإصدار 7.x أو إصدار أحدث.

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

الاصطلاحات

 أحلت cisco فني طرف إتفاق لمعلومة على وثيقة إتفاق.

معلومات أساسية

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

أساليب ترحيل DTMF المدعومة ل CUBE

يدعم CUBE مجموعة متنوعة واسعة من طرق ترحيل DTMF لكل من بروتوكولات إرسال إشارات بروتوكول بدء جلسة العمل (SIP) داخل النطاق وخارجه.

أساليب ترحيل DTMF المدعومة داخل النطاق

• صوت داخل النطاق DTMF حتى G711
• المعيار RFC2833

أساليب ترحيل DMTF المدعومة خارج النطاق

• H.245 أبجدي رقمي
• إشارة H.245
• إعلام SIP غير المرغوب فيه
• SIP KPML
• معلومات SIP

دعم DTMF للصوت داخل النطاق من خلال G711

يشير صوت داخل النطاق الصوتي أو G711 DTMF إلى نقل نغمات صوتية عبر تدفق صوت الصوت، دون أي تدخل إضافي لبروتوكول إرسال الإشارات أو DSP لإرسالها باستثناء إعداد المكالمة بشكل طبيعي وتمرير نهاية الصوت إلى النهاية واستخدام كوديك G711ULAW/Alaw. هذا يعني أن المكعب/Cisco IOS يمرر صوت النغمات فقط التي تأتي من نهاية إلى أخرى كما لو كان صوت عادي. الإجراء المهم الذي يجب إتخاذه لهذه الطريقة هو التأكد من تأسيس المكالمات واستخدام برنامج الترميز G711ULAW/Alaw تحديدا لأن إستخدام برنامج الترميز الذي من شأنه ضغط الصوت (أي برنامج ترميز آخر من G711) يؤدي إلى تشويه نغمات DTMF ومن المحتمل أن يجعلها غير معروفة إلى الطرف المتلقي. وذلك لأن خوارزمية الضغط المستخدمة من قبل برامج الترميز عالية الضغط تم تصميمها للتعرف على صوت الإنسان والتنبؤ به وليس درجات DTMF اللونية.

يتم دعم الصوت داخل النطاق/G711 DTMF مع أي بروتوكول إرسال إشارات VoIP ويتطلب فقط فرض برنامج الترميز G711 للاستدعاءات من نهاية إلى نهاية. يجب على المرء أيضا أن يضع في الاعتبار أن أي معالجة ترميز من ترميز منخفض معدل البت (LBR) إلى G711 على الأرجح يشوه النغمات أيضا.

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

أساليب ترحيل DTMF المدعومة ل H323 

H.245 أبجدي رقمي

يتم فصل أرقام DTMF من تدفق الصوت ويتم إرسالها من خلال قناة إرسال إشارات H.245 خارج النطاق (OOB) بدلا من إرسالها عبر قناة RTP. يتم نقل الدرجات اللونية في رسائل إشارة إدخال المستخدم H.245. تعد قناة إرسال إشارات H.245 قناة موثوقة، ويتم ضمان تسليم الحزم التي تنقل نغمات DTMF. يلزم توفر جميع الأنظمة المتوافقة مع H.323 الإصدار 2 لدعم الأمر dtmf-relay h245-alphanumber. ومع ذلك، فإن دعم الأمر dtmf-relay h245-signal إختياري.

إشارة H.245

تتيح طريقة OOB المماثلة لطريقة H.245 الأبجدية الرقمية، تمرير معلومات مدة النغمة، وبالتالي فإنها تعالج مشكلة محتملة تتعلق بطريقة أبجدية رقمية عند العمل البيني مع أنظمة موردين آخرين.

أحداث الهاتف المسماة (NTE) - RFC2833

تنقل هذه الطريقة نغمات DTMF في حزم RTP منفصلة وفقا للقسم 3 من RFC 2833. يحدد RFC 2833 تنسيقات حزم NTE RTP المستخدمة لنقل أرقام DTMF، وذاكرة Flash غير المستخدمة، والأحداث الهاتفية الأخرى بين نقطتي نهاية نظيرتين. باستخدام طريقة NTE، تقوم نقاط النهاية بإجراء التفاوض لكل مكالمة لمعلمات ترحيل DTMF لتحديد قيمة نوع الحمولة لحزم NTE RTP وأحداث أرقام NTE المدعومة. ونتيجة لذلك، يتم توصيل نغمات DTMF عبر حزم RTP مع قيمة نوع حمولة تختلف عن القيم التي تم التفاوض عليها لحزم الوسائط الأخرى، والتي توفر طريقة موثوقة لنقل الأرقام وتجنب عدم التعرف عليها عند ضغطها عبر برنامج الترميز المستخدم لترميز حركة مرور الصوت أو الفيديو أو الفاكس.

يعد ترحيل RFC2833/NTE DTMF طريقة داخل النطاق لأن الأرقام يتم نقلها داخل حركة مرور صوت RTP نفسها دون أي تدخل من بروتوكول إرسال إشارات GW.

من المهم الإشارة إلى أنه يجب عدم الخلط بين أسلوب RFC2833/NTE مع تدفق صوت داخل النطاق أو تدفق G711 RTP لأن الأحدث هو فقط النغمات الصوتية التي يتم تمريرها كصوت عادي دون أي طريقة إرسال إشارات ترحيل تكون مدركة للعملية أو مشتركة فيها. يعني أنها مجرد نغمات صوت عادية يتم تمريرها من نهاية إلى نهاية باستخدام كوديك G711Ulaw/Alaw.

بعض الحقائق الأخرى حول NTE مع H323:

• يدعم H.323 المعيار RFC2833 بدءا من الإصدار 4
• يعلن IOS دائما عن دعمه لعام 2833 في أجهزة التحكم
• يدعم CUCM تقنية NTE فقط من خلال H.323 ICT.

RTP الخاص من Cisco

مع هذه الطريقة يتم إرسال نغمات DTMF في نفس قناة RTP مثل البيانات الصوتية. على أي حال، فإن نغمات DTMF يتم ترميزها بشكل مختلف عن عينات الصوت، ويتم تعريفها كنوع حمولة 121، مما يمكن المتلقي من تعريفهم كنغمات DTMF. هذه الطريقة غير معتمدة من قبل CUCM وتم إيقاف إستخدامها.

أساليب ترحيل DTMF المدعومة ل SIP

NTE - RFC2833

يتم التفاوض حول أنواع حمولة NTE وسماتها داخل النطاق RFC2833 بين النهايتين في إعداد الاستدعاء الذي يستخدم بروتوكول وصف جلسة العمل (SDP) داخل قسم المتن من رسالة SIP.

إعلام غير مطلوب (UN)

باستخدام هذه الطريقة، يتم إرسال الأرقام خارج النطاق (OOB) كرسائل SIP NOTIFY داخل حمولة نص الرسالة.

لغة الترميز الصحفي الأساسية (KPML)

استنادا إلى RFC4730، يتم نقل الأرقام خارج النطاق (OOB) باستخدام XML داخل رسائل الاشتراك/الإعلام. يستخدم هذا المزيج في الغالب لنقاط نهاية SIP المسجلة في CUCM أو CME، ولكنه يستخدم أيضا مع ITSPs.

معلومات (معلومات)

يتم إرسال الأرقام كرسائل معلومات SIP من OOB بين النهايات. لا تتطلب هذه الطريقة أي تكوين ويتم قبولها وارتباطها بواسطة CUBE تلقائيا.

ملاحظة: معلومات SIP غير مدعومة من قبل Unified CM.

ملاحظة: عندما يتم التفاوض على كل من طريقتي UN و NTE، يختار Cisco IOS دائما UN عبر NTE لتجنب نغمات الألوان المزدوجة ويتم منع حزمة NTE داخل النطاق 2833. كما يتم إستخدام UN ل CUCM فقط عندما لا يتوفر خيار آخر. بالمثل، إذا كان كلا من KPML و UN حاضرين، فإن مدير المكالمات (CCM) من Cisco يختار KPML على UN.

تكوين ترحيل DTMF على CUBE

وبشكل افتراضي، يتم تعطيل ترحيل DTMF لكل من H323 و SIP نظائر الطلب (باستثناء معلومات SIP)؛ ومن الإلزامي تكوين أسلوب ترحيل DTMF لاستخدامه من نهاية إلى نهاية على كل من نظاري الطلب الوارد والصادر لكل نقطة اتصال.

تكوين ترحيل DTMF ل H323

Router(config)#dial-peer voice 1 voip
Router(config-dial-peer)#dtmf-relay ?
  cisco-rtp          Cisco Proprietary RTP
  h245-alphanumeric  DTMF Relay via H245 Alphanumeric IE
  h245-signal        DTMF Relay via H245 Signal IE
  rtp-nte            RTP Named Telephone Event RFC 2833

يمكنك تكوين أكثر من طريقة لكل نظير طلب، حسب متطلبات نهايات الإنهاء.

Router(config-dial-peer)#dtmf-relay rtp-nte ?
  cisco-rtp          Cisco Proprietary RTP
  digit-drop         Digits to be passed out-of-band and in-band digits dropped
  h245-alphanumeric  DTMF Relay via H245 Alphanumeric IE
  h245-signal        DTMF Relay via H245 Signal IE

تكوين ترحيل DTMF ل SIP

Router(config)#dial-peer voice 1 voip
Router(config-dial-peer)#dtmf-relay ?
  cisco-rtp          Cisco Proprietary RTP
  h245-alphanumeric  DTMF Relay via H245 Alphanumeric IE
  h245-signal        DTMF Relay via H245 Signal IE
  rtp-nte            RTP Named Telephone Event RFC 2833
  sip-kpml           DTMF Relay via KPML over SIP SUBCRIBE/NOTIFY 
  sip-NOTIFY         DTMF Relay via SIP NOTIFY  messages

 يمكنك تكوين أكثر من طريقة لكل نظير طلب، حسب متطلبات نهايات الإنهاء.

Router(config-dial-peer)#dtmf-relay rtp-nte ?
  cisco-rtp          Cisco Proprietary RTP
  digit-drop         Digits to be passed out-of-band and in-band digits dropped
  h245-alphanumeric  DTMF Relay via H245 Alphanumeric IE
  h245-signal        DTMF Relay via H245 Signal IE
  sip-kpml           DTMF Relay via KPML over SIP SUBSCRIBE/NOTIFY 
  sip-NOTIFY          DTMF Relay via SIP NOTIFY  messages

ملاحظة: أضف الأمر session protocol sip ضمن نظير الطلب لخيارات ترحيل SIP dtmf أن تصبح متوفرة.

تكوين إسقاط رقم ترحيل DTMF

لتجنب الأرقام المكررة من خلال نقل نفس أرقام DTMF من خلال أساليب داخل النطاق وخارجه إلى الجزء الصادر للمكالمات التي تعمل البيني من خلال النطاق الترددي (RTP-NTE بشكل محدد) إلى طريقة خارج النطاق، قم بتكوين الأمر dtmf-relay rtp-nte number-drop على نظير الطلب الوارد والطريقة المطلوبة خارج النطاق على نظير الطلب الصادر. وإلا، يتم إرسال نفس الرقم في خارج النطاق الترددي وكذلك داخل النطاق ويتم ترجمته كأرقام مكررة بواسطة طرف الاستلام.

عند تكوين خيار أرقام-إسقاط في الساق الواردة، يقوم المكعب بإيقاف حزم NTE وفقط أرقام الترحيل التي تستخدم طريقة OOB التي تم تكوينها على الساق الصادرة.

كما هو موضح في هذه الصورة، يتوفر خيار إسقاط الرقم عند العمل البيني بين طرق ترحيل DTMF هذه.

على سبيل المثال، قم بتكوين الأمر dtmf-relay rtp-nte number-drop على نظير الطلب الوارد لأرقام إرسال SIP من خلال RFC2833، ثم على جانب H.323 الصادر قم بتكوين إما dtmf-relay245-alphaumeric أو dtmf-relay245-signal، ويجب أن ينتج عن ذلك قمع CUBE لحزم NTE وإرسال أحداث OOB H245 فقط.

لمزيد من المعلومات، راجع إسقاط رقم ترحيل DTMF.

التحقق من صحة ترحيل DTMF واستكشاف أخطائه وإصلاحها

التحقق من صحة ترحيل OOB DTMF ل H323

إعلان H.245 حول إمكانية إستخدام أبجدية رقمية

للتحقق من صحة ما إذا كانت نقطة النهاية تقوم بالإعلان عن إمكانية H.245 أبجدية رقمية، ابحث عن هذا السطر داخل رسالة مجموعة قدرة المحطة الطرفية (TCS) H.245 باستخدام debug H245 asn1.

capability receiveUserInputCapability : basicString : NULL

مثال الإرسال H.245 أبجدي رقمي

فيما يلي مثال لنقطة نهاية تنقل الرقم 1 باستخدام الطريقة الأبجدية الرقمية H245 باستخدام تصحيح الأخطاء H245 asn1.

000510: Sep 28 19:02:02.716: H245 MSC OUTGOING PDU ::=
	value MultimediaSystemControlMessage ::= indication : userInput : alphanumeric : "1“ 

إعلان إمكانية إشارة H.245

لتأكيد ما إذا كانت نقطة النهاية هي إعلان إمكانية إشارة H.245، ابحث عن هذا السطر داخل رسالة مجموعة قدرة المحطة الطرفية (TCS) H.245 التي تستخدم تصحيح الأخطاء H245 ASN1.

capability receiveUserInputCapability : dtmf : NULL

مثال إرسال إشارة H.245

هذا مثال على نقطة نهاية ترسل الرقم 1 مع مدة 100 مللي ثانية باستخدام طريقة الإشارة H245. هناك رسالتان، تشير الرسالة الأولى إلى الرقم الذي تم طلبه لمدة 4s. ومع ذلك، تقوم الإشارة الثانية (signalUpdate) بتحديث قيمة مدة الرقم إلى 100 مللي ثانية بدلا من ذلك.

000555: Sep 28 19:12:05.364: H245 MSC OUTGOING PDU ::=
		 value MultimediaSystemControlMessage ::= indication : userInput : signal :
		    {
		      signalType "1"
		      duration 4000
		    }
000558: Sep 28 19:12:05.368: H245 MSC OUTGOING PDU ::=
		 value MultimediaSystemControlMessage ::= indication : userInput : signalUpdate :
		    {
		       duration 100
		       rtp
		      { 
                        logicalChannelNumber 2
		      }

تأكيد ترحيل DTMF داخل النطاق ل H323

يمكن أن تشير نقاط النهاية التي تحتوي على H.323 V5 إلى أنها تدعم RFC2833 من خلال رسالة قدرة داخل رسالة TerminalCapabilitySet (TCS).

إعلان دعم الإمكانات RFC2833

لتأكيد ما إذا كانت نقطة نهاية تقوم بالإعلان عن قدرة RFC2833، ابحث عن هذه البنية داخل رسالة TCS H.245 التي تستخدم تصحيح الأخطاء H245 asn1 (في المثال، يتم الإعلان عن نوع الحمولة 101 للأحداث من 0 إلى 16).

capabilityTableEntryNumber 34
          capability receiveRTPAudioTelephonyEventCapability :
          {
            dynamicRTPPayloadType 101
            audioTelephoneEvent "0-16"
          }

التحقق من ترحيل OOB DTMF ل SIP

مثال إعلان إعلام غير مطلوب (UN)

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

INVITE sip:9999@192.168.106.66:5060 SIP/2.0
	Call-Info: <sip:192.168.106.50:5060>;method="NOTIFY ;Event=telephone-event;Duration=2000“

مثال إرسال إخطار (UN) غير مطلوب

يرسل أسلوب UN الأرقام كبيانات ثنائية داخل رسالة NTFY؛ لذلك لا يمكنك رؤية الرقم الذي يتم نقله باستخدام رسائل debug ccsip. يمكنك إما أن تحتاج إلى التقاط الحزمة (PCAP) أو أن تقوم بتشغيل الأمر debug ccsip all لترى الرقم ضمن مخرجات البيانات الثنائية.

مثال على كيف سيبدو نفس الرقم 7 المطلوب عند تشغيل الأمر debug ccsip all.

001738: Oct  9 15:37:24.577: //-1/xxxxxxxxxxxx/SIP/Msg/sipDisplayBinaryData:
 Sending: Binary Message Body
001739: Oct  9 15:37:24.577: Content-Type: audio/telephone-event
07 00 07 D0

001756: Oct  9 15:37:24.577: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
NOTIFY sip:9999@192.168.106.66:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.106.50:5060;branch=z9hG4bK10E8E5C
From: <sip:2010@192.168.105.189>;tag=557BFE8-9EE
To: <sip:9999@192.168.106.66>;tag=cuecebad539
Call-ID: 87C4CAE-115E11E2-8184AAE4-EF882E8F@192.168.253.1
CSeq: 106 NOTIFY
Event: telephone-event
Subscription-State: active
Contact: <sip:192.168.106.50:5060>
Content-Type: audio/telephone-event
Content-Length: 4

001763: Oct  9 15:37:24.593: //0/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 Ok
Via: SIP/2.0/UDP 192.168.106.50:5060;branch=z9hG4bK10E8E5C
To: <sip:9999@192.168.106.66>;tag=cuecebad539
From: <sip:2010@192.168.105.189>;tag=557BFE8-9EE
Call-ID: 87C4CAE-115E11E2-8184AAE4-EF882E8F@192.168.253.1
CSeq: 106 NOTIFY
Content-Length: 0
Allow-Events: refer
Allow-Events: telephone-event
Allow-Events: message-summary

لغة ترميز الضغط الأساسية (KPML) Aمثال التصميم

يتم سرد إمكانية KPML في رأس SIP ل Allow-Events. بالنسبة لعمليات إرسال أرقام KPML، تحتاج نقطة نهاية الإرسال إلى إرسال اشتراك أولا إلى خدمة KPML؛ إرسال رسالة SUBSCRIBE تطلب القدرة؛ يتبعها رسالة NOTIFY من الطرف المتلقي الذي يحدد حالة الاشتراك لأحداث KPML كنشاط.

قدرة الإعلان عن الدعوة الأولية.

INVITE sip:95554445001@192.168.105.25:5060 SIP/2.0 
Allow-Events: kpml, telephone-event

يطلب إنهاء الخدمة الاشتراك في أحداث KMPL.

SUBSCRIBE sip:2010@192.168.106.50:5060 SIP/2.0
Event: kpml 
Content-Type: application/kpml-request+xml 

تستجيب النهاية المنشئة بإعداد "إعلام" بحيث تصبح الحالة نشطة.

NOTIFY  sip:192.168.105.25:5060 SIP/2.0
Event: kpml 
Subscription-State: active

كي إم إل تيمثال على المراوغة

بعد تنفيذ الاشتراك، يمكن لنقاط النهاية إرسال الأرقام باستخدام رسائل NOTIFY مع أحداث KPML من خلال XML. مثال على نقل الرقم 1.

NOTIFY  sip:192.168.105.25:5060 SIP/2.0
Event: kpml 
<?xml version="1.0" encoding="UTF-8"?>
<kpml-response version="1.0" code="200" text="OK" digits="1" tag="dtmf"/> 

العمل البيني ل DTMF

يدعم CUBE حوالي 30 نوعا مختلفا من العمل البيني ل DTMF. وهو قادر على العمل البيني والتشفير بين طرق الترحيل المختلفة استنادا إلى الأمر dtmf-relay الذي تم تكوينه داخل نظائر الطلب الواردة والصادرة المطابقة للمكالمة.

راجع قسم جدول قابلية التشغيل البيني ل DTMF من دليل تكوين CUBE للحصول على تفاصيل حول دعم العمل البيني ل DTMF. 

متى يتطلب المكعب موارد ترميز DTMF

يتطلب CUBE موارد تحويل الترميز المسجلة محليا في هذه السيناريوهات

• العمل البيني بين RFC2833 والصوت داخل النطاق
• العمل البيني بين طريقة خارج النطاق (OOB) و RFC2833 للمكالمات المتدفقة

يمكن أن يتفاعل CUBE بين جميع طرق ترحيل DTMF الأخرى مع مكالمات تدفق-عبر بدون الحاجة إلى جهاز إرسال/إستقبال.

العمل البيني ل DTMF بين النطاق الداخلي G711 إلى RFC2833

يمكن أن يتداخل CUBE بين G711 DTMF داخل النطاق (درجات صوت أولية) إلى RFC2833. غير أن هذه المتطلبات بحاجة إلى الوفاء بها

• يجب أن يكون برنامج الترميز المستخدم من G711 شاملا. هذا قيد لأنه إذا كان شفرة LBR سيتم إستخدامها، عندئذ سيتم تشوه الدرجات اللونية بسبب فقدان الضغط.
• يجب أن تكون موارد الترميز اللغوي متوفرة ومسجلة مع CUBE وفقا لذلك. وذلك لأن المكعب يحتاج إلى تخصيص مورد ترميز (بشكل أكثر تحديدا: مورد DSP) إلى دفق RTP للوسائط لحقن أو الاستماع إلى النغمات اللونية ضمن دفق الصوت.
• يجب ألا يحتوي نظير الطلب الخاص بالساق داخل النطاق الترددي على أي أمر ترحيل DTMF تم تكوينه. لم يعد هذا المتطلب ضروريا ل IOS XE 16.12.x أو الأحدث. يمكن أن يقوم CUBE بتخصيص جهاز إرسال/إستقبال حتى إذا كان نظير الطلب الوارد/ITSP قد تم تكوين DTMF-relay rtp-nte. ويمكن أن يعتمد قرار تخصيص جهاز إرسال/إستقبال على تفاوض SDP بين الأجهزة النظيرة.
• يجب أن يكون نظير الطلب الخاص بالساق RFC2833 قد تم تكوين dtmf-relay rtp-nte.
• لا تقم بتمكين الإسقاط الرقمي على أي من نظائر الطلب المعنية بالمكالمة.

خيارات DTMF الأخرى للعمل البيني

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

dtmf-interworking {rtp-nte | standard | system} 
	rtp-nte	Enables a delay between the dtmf-digit begin and dtmf-digit end events of RTP NTE packets. 
	Standard	Generates RTP NTE packets that are RFC 4733 compliant. 
	System	Specifies the default global DTMF interworking configuration. This keyword is available only in dial peer voice configuration mode.

متى تكون موارد MTP مطلوبة من قبل CUCM

يصبح مورد MTP ضروريا عندما يحتاج CUCM إلى العمل البيني بين طرق DTMF المختلفة بين جهازين، أحدهما يستخدم طريقة RFC2833 بشكل محدد والآخر طريقة OOB. في هذا السيناريو، يحتاج CUCM إلى تخصيص الموارد اللازمة لإرسال و/أو اكتشاف الألوان داخل النطاق الترددي بسبب عدم تطابق ترحيل DTMF بين النهايتين.

دور MTP هو مراقبة حركة مرور RTP واكتشاف أحداث NTE من ساق RFC2833 أو إدخال أحداث NTE في تدفق RTP إذا طلب ذلك من قبل CUCM. إذا اكتشفت MTP أحداث NTE الواردة من نقطة النهاية التي تدعم RFC2833 فقط، فإنها ترسل محطة SCCPStationNOTIFYDtmfToneMessage إلى CUCM وتعلمه بالنغمة التي تم الكشف عنها في الدفق. يرسل CUCM بدوره نفس الرقم ويستخدم بروتوكول إرسال الإشارات (OOB) إلى الطرف الآخر. إذا كان CUCM يتلقى إشارة DTMF من OOB من نقطة نهاية DTMF، فإنه يرسل SCCP StationSendDtmfToneMessage إلى MTP بحيث يمكن MTP إدخال النغمة المطلوبة في دفق RTP في شكل أحداث NTE.

أجهزة MTP المدعومة من قبل CUCM

برنامج MTP (تطبيق تدفق الوسائط الصوتية ل Cisco IP)

برنامج MTP هو جهاز يتم تنفيذه من خلال تمكين تطبيق تدفق الوسائط الصوتية ل Cisco IP على خادم CUCM. عندما يتم تكوين التطبيق المثبت كتطبيق MTP، فإنه يقوم بالتسجيل مع عقدة CUCM ويعلم CUCM عن عدد موارد MTP التي يدعمها. يدعم جهاز MTP للبرنامج تدفقات G.711 فقط. تسمح الإعدادات الافتراضية ل CUCM بمعالجة ما يصل إلى 48 مكالمة وفقا ل MTP الخاص بالبرنامج. للحصول على تفاصيل حول كيفية تعديل معلمات الخدمة، ارجع إلى الإصدار المناسب من دليل إدارة إدارة الاتصالات الموحدة من Cisco.

برنامج MTP (استنادا إلى برنامج Cisco IOS)

يسمح بروتوكول MTP هذا بتكوين أي من هذه المشفرات، ومع ذلك يمكن تكوين واحد فقط في وقت معين G.711 MU-Law و G.729a و G.729 و G.729ab و G.729b والمرور. وبعض هذه التدابير لا تتصل بتنفيذ إتفاقية حفظ الطبيعة في القرن الأفريقي.

تتيح تكوينات الموجه ما يصل إلى 1000 تدفق فردي، وهو ما يدعم 500 جلسة عمل تم ترميزها والتي تولد 10 ميجابت من حركة المرور. يمكن أن تدعم موجهات Cisco ISR G2s و ASR أرقاما أعلى بشكل ملحوظ من هذا.

يستهلك بروتوكول MTP هذا دورات وحدة المعالجة المركزية (CPU) للعمل. دون عدد جلسات العمل الممكنة حيث يمكن أن تؤثر على أداء وحدة المعالجة المركزية (CPU) وتثير إستخدام وحدة المعالجة المركزية (CPU) بشكل كبير.

بروتوكول MTP للأجهزة (PVDM2 و Cisco NM-HDV2 و NM-HD-1V/2V/2VE)

يستخدم هذا الجهاز الوحدات النمطية PVDM-2 لتوفير DSPs.

جهاز MTP (موجهات السلسلتان 2900 و 3900 من Cisco مع PVDM3)

تستخدم هذه الموجهات وحدات DSP الخاصة بالمحول PVDM3 بطبيعتها على اللوحات الأم أو PVDM2 باستخدام مهايئ على اللوحة الأم أو على الوحدات النمطية للخدمة.

ملاحظة: لا يمكنك تكوين G.729 أو G.729b عند تكوين موارد MTP للأجهزة في Cisco IOS. ومع ذلك، يمكن ل Unified CM إستخدام موارد ترميز الأجهزة ك MTP في حالة استنفاد جميع موارد MTP الأخرى أو عدم توفرها بشكل آخر.

متى يمكن إستخدام البرنامج أو الجهاز MTP

يعتمد نوع MTP الذي سيتم نشره في شبكتك على معلمات برنامج الترميز المحددة المدعومة بنقاط النهاية والعبارات وخطوط الاتصال في تدفق المكالمات

• نكهات برنامج الترميز المراد إستخدامها
• حجم حزمة برنامج الترميز المطلوب إستخدامها (ربط البيانات)
• إستخدام إرسال الفاكس T.38 (يتطلب دعم تمرير برنامج الترميز)

استنادا إلى هذه المعلمات، يمكنك إختيار الموارد الصحيحة المطلوبة من قبل الشبكة ونشرها بأمان.

كما هو موضح في الجدول، الميزات المختلفة التي تدعمها أنواع MTP و Transcoder المختلفة

النوع	نفس الترميز	برامج تشفير مختلفة	تعبئة مختلفة	كوديك مرق	ملاحظات
CUCM SW MTP	نعم	لا	نعم	لا	G711 Alaw-Ulaw الترميز وإعادة الربط
Cisco IOS HW MTP	نعم	لا	لا	نعم	دعم أي برنامج ترميز (ونفس النكهة) طالما تم تعيين نفس الحزمة. لا يوجد ترميز.
Cisco IOS SW MTP	نعم	لا	لا	نعم	دعم أي برنامج ترميز (ونفس النكهة) طالما تم تعيين نفس الحزمة. لا يوجد ترميز.
برنامج IOS Regular Xcoder من Cisco	نعم	نعم	نعم	نعم	وطالما كان جانب واحد على الأقل هو G711u/G711a، فإنه يدعم أي إعادة حزم وترميز.
برنامج IOS Universal Xcoder من Cisco	نعم	نعم	نعم	نعم	الدعم في أي برنامج ترميز وتوسيم حزم وترميز.

للحصول على مزيد من المعلومات حول تكوين MTP في CUCM، يرجى الرجوع إلى مثال تكوين نقطة نهاية الوسائط .

اعتبارات مجموعة موارد الوسائط (MRG) CUCM وقائمة مجموعة موارد الوسائط (MRGL) ل MTP

عند إنشاء موارد الوسائط وتعيينها لمجموعات موارد الوسائط (MRG) وقوائم مجموعات موارد الوسائط (MRGL)، خذ بعض النقاط الإضافية في الاعتبار لتجنب الاكتتاب الزائد في أفضل الموارد لتدفقات المكالمات المحددة وترتيبها حسب الأولوية وفقا لذلك. يتعذر على CUCM انتقاء أفضل جهاز لاستخدامه، عندما يحدد مورد وسائط لإجراء مكالمة، من قائمة محددة من MTPs والمحولات إذا كانت لها نفس الأولوية أو الأمر. وبدلا من ذلك، فإنه يختار الجهاز الأول الذي يدعم الإمكانات المطلوبة. لذلك حتى إذا كان الاتصال يستخدم G711 على كلا القدمين، إذا كان الجهاز الأول الذي وجده هو جهاز تحويل برمجي، فإنه يقوم بتخصيصه ك MTP للمكالمة ولا يبحث عن مورد MTP أسفل القائمة.

يحدث سلوك مماثل آخر عندما يكون لديك محولات عالمية ومنتظمة. يمكن أن يستخدم CUCM المحولات العادية أولا في مكالمة حيث إحدى الساقين هي G711، ثم يفشل عندما يتم تحويل مكالمة إلى وجهة تستخدم كوديك غير G711، لأن CUCM لن تطلق المحول الحالي وتحصل على آخر عندما يتم نقل المكالمة.

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

رسائل SCCP MTP

يتم تبادل رسائل SCCP هذه بين موارد CUCM و MTP لمعالجة DTMF.

•  StationCapabilitiesRes
•  StationUpdateCapabilities
•  StationSubscribeDtmfPayloadReq
•  StationSubscribeDTMFPayloadErrv
•  StationSubscribeDtmfPayloadRes
•  StationUnsubscribeDtmfPayloadErr
•  StationNOTIFYDtmfToneMessage
•  StationSendDtmfToneMessage
•  StationUnsubscribeDtmfPayloadReq
•  StationUnsubscribeDtmfPayloadRes

ترحيل DTMF بين CUCM و CUBE

خط اتصال CUCM SIP إلى المكعب

يدعم CUBE KPML أو NTE أو الإعلام غير المطلوب كآلية DTMF، حسب تكوينها. نظرا لإمكانية وجود مزيج من نقاط النهاية في النظام، يمكن تكوين طرق متعددة على المكعب في نفس الوقت لتقليل متطلبات MTP.

على CUBE، قم بتكوين كل من sip-kpml و rtp-nte كطرق ترحيل DTMF تحت نظائر طلب SIP. ويتيح هذا التكوين تبادل DTMF مع جميع أنواع نقاط النهاية، بما في ذلك تلك التي تدعم فقط NTE وتلك التي تدعم أساليب OOB فقط، دون الحاجة إلى موارد MTP. باستخدام هذا التكوين، تتفاوض البوابة مع NTE و KPML على حد سواء باستخدام CUCM. إذا لم يكن NTE مدعوما من قبل نقطة نهاية Unified CM، بعد ذلك يتم إستخدام KPML لتبادل DTMF. وإذا تم التفاوض على كلتا الطريقتين بنجاح، تعتمد البوابة على NTE لتلقي أرقام ولا تشترك في KPML.

كما يحتوي CUBE على إمكانية إستخدام أسلوب الإعلام غير المرغوب فيه (UN) ل DTMF. يرسل أسلوب UN رسالة SIP Notify مع نص يحتوي على نص يصف نغمة DTMF. هذه الطريقة مدعومة أيضا على CM الموحد ويمكن إستخدامها إذا لم يتوفر sip-kpml. قم بتكوين sip-notify كأسلوب ترحيل DTMF. لاحظ أن هذه الطريقة خاصة ب Cisco.

لا يمكن ل CUBEs التي تم تكوينها لترحيل NTE فقط، أو بسبب بعض قيود العمل البيني، إلا توفير موارد NTE و MTP المطلوبة لتخصيصها على جانب CUCM عند الاتصال بنقاط النهاية التي لا تدعم NTE.

يمكنك العثور على مزيد من المعلومات حول متطلبات MTP لشنطة CUCM

خط اتصال CUCM H323 إلى المكعب

يختار CUCM بشكل ديناميكي طريقة نقل DTMF لشبكات H323، وبالتالي لا توجد خيارات قابلة للتكوين لاختيار واحدة على الأخرى. إذا كنت ترغب في فرض طريقة ترحيل DTMF معينة، فيمكنك القيام بذلك من تكوين طلب نظير CUBE لشنطة هذه.

حتى عندما يدعم المكعب H323 NTE، يجب ألا يتم إستخدام خيار NTE لأنه غير مدعوم على CUCM لبوابات/خطوط اتصال H.323 في هذا الوقت؛ لذلك لا يعلن CUCM عن هذه الإمكانية في لحظة تبادل إمكانيات وسائط H245. الخيار المفضل ل CUCM هو إشارة H.245.

يلزم توفر موارد MTP لإنشاء مكالمات إلى مكعب H.323 إذا لم تكن نقطة النهاية الأخرى لديها إمكانية إرسال الإشارات المشتركة مع CUCM. على سبيل المثال، يدعم هاتف بروتوكول الإنترنت الموحد من Cisco طراز 7960 الذي يشغل مكدس SIP بطاقات واجهة الشبكة (NTE) فقط، لذلك يلزم وجود بروتوكول MTP مع خط اتصال H.323 وبالتالي يمكن إستخدام الرقم الهجائي H245 على الساق H323.

الحمولات الديناميكية/غير المتماثلة للمكعب

اعتبارا من تقديم Cisco IOS الإصدار 15.1(1)T (CUBE 1.4) لدعم العمل البيني لنوع الحمولة الديناميكية ل DTMF وحزم الترميز ل SIP إلى مكالمات SIP.

تتيح هذه الميزة ل CUBE التعامل مع العمل البيني ل: أنواع الحمولة الديناميكية لمشفرات الصوت/الفيديو و NSE و DTMF، والتي كانت محدودة حتى هذه النقطة لأن برنامج Cisco IOS سيحتفظ بنطاق ثابت ويسمح فقط لنفس أنواع الحمولة بالتفاوض على كل من مسدسي-LEG ورفض المكالمة باستخدام إستجابة خطأ 488 ل mismatch audio/video /NSE codecs (أو الرجوع إلى حزمة الصوت G711 DTMF) لحمولات NTE غير المطابقة. لذلك، تسمح الميزة للمكعب بإلغاء حجز أنواع الحمولة أو تحريرها ديناميكيا للعمل البيني مع موفري SIP أو الأجهزة التابعة لجهات خارجية التي تستخدم نطاق مختلف من أنواع الحمولة إلى نقطة أخرى لا تدعمها أو تتطلب تعيين مختلف بشكل محدد.

يعد نقطة الاتصال على CUBE متماثلا أو غير متناظر استنادا إلى قيمة نوع الحمولة المتبادلة من خلال SDP أثناء العرض والإجابة مع نقطة النهاية.

• تقبل نقطة النهاية المتماثلة نوع الحمولة نفسه لأحداث NTE أو برنامج ترميز محدد لمحطة الاتصال وترسل إليه.
• يمكن لنقطة النهاية غير المتماثلة قبول أنواع حمولة مختلفة وإرسالها لأحداث NTE أو برنامج ترميز محدد ل نقطة الاتصال.

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

asymmetric payload {dtmf | dynamic-codecs | full | system}

لمزيد من المعلومات حول الحمولات الديناميكية/غير المتماثلة، الرجاء الانتقال إلى العمل البيني لنوع الحمولة الديناميكية لحزم DTMF وترميز SIP لمكالمات SIP

مثال على الحمولات المتماثلة

هنا مثال من كيف ال SDP سيبدو هكذا ل متماثل حمولة مفاوضة و الإنتاج من ال debug voIP جلسة rtp يعين حادث بينما DTMF الدرجة اللونية يكون بثثت. يرجى ملاحظة أن التكوين المستخدم لإجبار Cisco IOS يمكن أن يستخدم نوع حمولة مختلف لأحداث NTE التي تستخدم الأمر rtp payload-type nte.

تفاوض ترحيل DTMF

إرسال ترحيل DTMF

مثال على الحمولات غير المتماثلة

هنا مثال من كيف ال SDP سيبدو هكذا ل غير متماثل حمولة تفاوض و الإنتاج من ال debug voip rtp جلسة يعين أمر حدث بينما DTMF الدرجة اللونية يكون بثثت. يرجى ملاحظة التكوين المستخدم لإجبار Cisco IOS على إستخدام نوع حمل مختلف لأحداث NTE واستخدام أوامر rtp payload-type nte وVoice-class asymmetric payload dtmf CLI.

تفاوض ترحيل DTMF

بث ترحيل DTMF

أسلوب ترحيل DTMF الذي سيتم إستخدامه

 عندما تختار ترحيل DTMF لاستخدامه، تحتاج إلى مراعاة هذه المتغيرات.

• الأجهزة والأنظمة الأساسية المعنية.
• بروتوكولات VoIP المعنية.
• مسار الوسائط والشفرات المدعومة.
• أساليب ترحيل DTMF المدعومة أو المفضلة.

أساليب ترحيل DTMF المفضلة ل H.323

الطريقة المفضلة ل H323 هي إستخدام OOB من خلال H.245 أبجدية رقمية أو إشارة في جميع السيناريوهات تقريبا. أنت يستطيع أيضا استعملت RFC2833 طالما أن CUCM ليس متورط.

أساليب ترحيل DTMF المفضلة ل SIP

• توصيل SIP لمزودي الخدمة - كلما كان هناك خط اتصال SIP إلى موفر SIP متورط أو تفاعل مع 3^سطح ويفضل إستخدام أجهزة SIP أو أنظمة IVR داخل النطاق من خلال RFC2833.
• خط اتصال SIP إلى CUCM أو CME - يمكن كلا من RFC2833 و KPML.
• خط اتصال SIP إلى CUE - الطريقة الافتراضية ل CUE هي UN ولكن يمكنك أيضا تكوينها لاستخدام NTE؛ وهو أيضا الخيار الأفضل إذا كانت المكالمة تأتي من موفر SIP إلى نظام CUE.

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

دعم تشفير الصوت العالمي لعبارات IP إلى IP

تحويل DTMF

مثال تكوين تحويل ترميز العنصر الحدودي الموحد

إستخدام Cisco Unified Communications Manager لتكوين نقطة ترميز الوسائط وإنهائها

تكوين إسقاط رقم ترحيل DTMF على عنصر حدود موحد من Cisco

متطلبات SIP Trunk MTP

أسلوب معلومات SIP لإنشاء نغمة DTMF

توصيل H.323 مع نقاط إنهاء الوسائط

واجهة ترميز المحول المحلية (LTI) ل CUBE 9.0