فهم الاتصال الداخلي المباشر (DID) على واجهات IOS Voice Digital (T1/E1)

تم ترحيل هذا المستند إلى سير عمل النشر الذاتي. وقد نشر في الأصل على الموقع https://www.cisco.com/c/en/us/support/docs/voice/digital-ccs/14072-direct-inward-dial.html.
يجب تحديث هذا المستند ليتوافق مع الإرشادات الحالية ويجب إزالة هذه الملاحظة قبل النشر. عندما تقوم بنشر هذا المستند للمعاينة، تأكد من أن معرف المستند هو 14072 وأن عنوان URL يطابق عنوان URL الأصلي الموجود في هذه الفقرة. إذا لم يتطابق معرف المستند أو عنوان URL، فاتصل ب tz-writers@cisco.com.

المقدمة

يصف هذا المستند الموجهات/البوابات التي تدعم الصوت من Cisco IOS® باستخدام الواجهات الرقمية (T1/E1). لمزيد من المعلومات حول الاتصال الداخلي المباشر التناظري (DID) من Cisco، ارجع إلى: DID التناظري لموجهات سلسلة 2600 و 3600 من Cisco

ملاحظة: في معظم الأنظمة الأساسية، يتم تمكين DID بشكل افتراضي على واجهات CAS (الفورية، والشباك، والتأخير). لذلك، لا تقم بتكوين أمر الطلب الداخلي المباشر للمكالمات الواردة. على منصات Cisco AS5300، DID غير مدعوم على الواجهات التي تم تكوينها لإشارات E & M الفورية.

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

المتطلبات

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

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

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

الاصطلاحات

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

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

DID هي خدمة تقدمها شركات الهاتف تمكن المتصلين من الاتصال مباشرة بملحق في Private Branch Exchange (PBX) أو نظام صوت الحزمة دون مساعدة من مشغل أو خادم مكالمات مؤتمت. تستخدم هذه الخدمة خطوط الاتصال DID، والتي تقوم بإعادة توجيه آخر ثلاثة إلى خمسة أرقام فقط من رقم الهاتف إلى PBX أو الموجه/البوابة. على سبيل المثال، إذا كانت إحدى الشركات تتوفر على ملحقات الهواتف من 555-1000 إلى 555-1999، وكان المتصل يطلب 555-1234، فإن المكتب المركزي المحلي (CO) سيقوم بإعادة توجيه 234 إلى نظام PBX أو نظام صوت الحزمة. عندئذ سيقوم نظام PBX أو نظام صوت الحزمة (Cisco CallManager وموجه/عبارة IOS) بطلب الملحق 234. هذه العملية بالكامل شفافة للمتصل.

في هذا المستند، نناقش نوعين من أقران الطلب على النحو التالي:

• خدمة الهاتف القديمة العادية (POTS) — هذه مكالمة صوتية تقليدية يتم وضعها عبر شبكة الهاتف العامة المحولة (PSTN) حيث يمكنك الحصول على نقطة اتصال دائرية متكاملة بسرعة 64 ألف لفة في الدقيقة طوال مدة المكالمة. سيشير نظير الطلب POTS دائما إلى منفذ صوت على الموجه

• الشبكة الصوتية—تتألف المكالمة الصوتية عبر شبكة البيانات من عدة أدوات اتصال. وتتنقل كل جهة اتصال بين أجهزة البيانات (الموجهات/البوابات) أو بين أجهزة البيانات والهواتف (مثل موجه إلى جهاز PBX). يشير نظائر طلب الشبكة الصوتية إلى وجهات مختلفة وفقا لتقنية الشبكة المستخدمة. تتضمن نظائر طلب الشبكة الصوتية ما يلي:

  • الصوت عبر بروتوكول الإنترنت (VoIP)

  • الصوت عبر ترحيل الإطارات (VoFR)

  • الصوت عبر ATM (VoATM)

  • بريد الوسائط المتعددة عبر IP (MMoIP)

عندما تأتي مكالمة صوتية في موجه/بوابة Cisco IOS، يتم مصادرة المنفذ الصوتي على الموجه الوارد بواسطة محول PBX أو CO. ثم يعرض الموجه/البوابة نغمة طلب للمتصل ويجمع الأرقام حتى يتمكن من تحديد نظير طلب صادر. سواء كانت الأرقام متصلة بفترات غير منتظمة من قبل البشر أو بشكل منتظم من خلال أجهزة هاتفية ترسل أرقام تم تجميعها مسبقا، فإن مطابقة نظير الطلب تتم من رقم إلى رقم. هذا يعني أن الموجه/البوابة تحاول مطابقة نظير طلب بعد تلقي كل رقم. تسمى هذه العملية الاتصال على مرحلتين.

ومع ذلك، إذا قام محول PBX أو CO بإرسال رسالة إعداد تحتوي على "جميع" الأرقام اللازمة لتوجيه المكالمة بالكامل، يمكن تعيين هذه الأرقام إلى نظير اتصال شبكة صوتية صادرة مباشرة. باستخدام DID، لا يقدم الموجه/البوابة نغمة طلب للمتصل ولا يجمع الأرقام. وهو يعيد توجيه المكالمة مباشرة إلى الوجهة التي تم تكوينها. يسمى هذا الاتصال من مرحلة واحدة.

الأرقام اللازمة لتوجيه المكالمات التي ناقشناها في الفقرات أعلاه هي من النوعين التاليين:

• خدمة التعرف على الرقم الرقمي (DNIS) هي خدمة رقمية توفرها شركة Telco توفر الرقم المستدعي (الرقم المطلوب).

• التعرف التلقائي على الرقم (ANI) هي خدمة رقمية توفرها شركة Telco وتقدم رقم الاتصال (عدد منشئ المكالمة). يشار إلى ANI أيضا باسم تعريف خط الاتصال (CLID).

DID تشكيل ل POTS طلب نظير

عند تلقي مكالمة واردة من واجهة خدمة هاتف عادية قديمة (POTS)، تتيح ميزة DID في نظائر الطلب للموجه/البوابة إمكانية إستخدام الرقم المستدعي (DNIS) لمطابقة نظير الطلب الصادر مباشرة. عند تكوين DID على نظير طلب POTS الوارد، يتم إستخدام الرقم المستدعي تلقائيا لمطابقة نمط الوجهة الخاص بجهة الاتصال الصادرة.

لتكوين نظير طلب POTS ل DID، أدخل أوامر Cisco IOS التالية التي تبدأ في وضع التكوين العام:

Router(config)#dial-peer voice number pots		
Router(config-dial-peer)#direct-inward-dial

مطابقة نظير طلب POTS الوارد الصحيح ل DID

لكي يعمل DID بشكل صحيح، تأكد من تطابق المكالمة الواردة مع نظير POTS الصحيح حيث تم تكوين الأمر direct-inward-dial. لمطابقة نظير الطلب الوارد الصحيح، نوصي باستخدام أمر نظير الطلب الوارد call-number dnis_string ضمن نظير اتصال DID POTS.

تتضمن الأوامر الأخرى المستخدمة لمطابقة نظائر الطلب: response-address ani_string، destination-style stringأو port voice-port . ميزة إستخدام الأمر الوارد call-number هي أن كل مكالمة تحتوي على معلومات DNIS (تسمى-number) المقترنة ولها أولوية على الأوامر السابقة.

إذا لم تكن تستخدم الأمر الوارد call-number لمطابقة نظير الطلب الوارد، فعليك مراعاة ما يلي:

• إذا كنت تستخدم معلومات ANI لمطابقة نظير الطلب POTS، فتأكد من تكوين عنوان إجابة الأمر بشكل صحيح ويقوم محول telco-switch بتوفير معلومات ANI. لا توفر بعض موفري ISDN ومعظم الإشارات المرتبطة بالقناة T1 (CAS)، باستثناء مجموعة الميزات D (FGD)، معلومات ANI.

• إذا لم يتم تطابق عنوان الإجابة مع ANI، فقد يكون ANI مطابقا لنمط الوجهة الذي تم تكوينه (للطلب الصادر) أسفل نظير طلب POTS آخر. إذا تمت مطابقة نمط الوجهة مقابل ANI، فتأكد من تكوين الأمر الاتصال الداخلي المباشر أسفل هذا الطلب-النظير.

• إذا لم تتم مطابقة إستدعاء DID الوارد مع POTS الوارد بالطلب-نظير استنادا إلى المستدعي الوارد أو response-address أو destination-style أو port، فسيتم إستخدام نظير الطلب الافتراضي 0. DID معطل بشكل افتراضي على نظير الطلب 0.

دراسة الحالة

أستخدم المثال التالي، لإيضاح النقاط المذكورة آنفا. تمتلك شركة ACME خطوط T1 PRI مع 40 خط اتصال DID في النطاق من 555-3100 إلى 555-3139. الهدف هو تخصيص أول 20 خطا لهواتف بروتوكول الإنترنت (IP) من Cisco. تتوفر آخر 20 سطر للاختبار والتوسعة في المستقبل، ويقوم الموجه في الوقت الحالي بمنح نغمة الطلب فقط. بافتراض أن محول CO يرسل آخر خمس أرقام فقط في رسالة إعداد ISDN، يمكننا تلخيص المعلومات الواردة أعلاه في الجدول التالي.

طلب مستخدمي PSTN	أرقام مرسلة بواسطة المحول إلى موجه/بوابة الصوت	إستخدام	# خطوط الاتصال
555-3100 إلى 555-3119	53100 - 53119	خطوط خطوط IP للهواتف	20
555-3120 إلى 555-3139	53120 - 53139	الاختبار والتوسع المستقبلي	20

التكوين

ملاحظة: يتم حذف بعض المخرجات في هذا المثال.

dial-peer voice 2 pots 
        destination-pattern 9T 
        port 1/0:23

 !--- This dial-peer is used mainly for outbound dialing with the !--- destination-pattern 9T mapped to port 1/0:23. Note that 9 is an !--- explicit match and will be stripped. Say a call comes from the CallManager !--- with a DNIS 914085551126, the router will send only 14085551126. If you add !--- the dial-peer command prefix 9 or the command forward-digit all then !--- the string 914085551126 is sent. Notice that dial-peer voice 2 pots is also !--- matched to give dial tone to incoming users dialing this range: !--- (53120 - 53139).

     dial-peer voice 3 pots 

 !--This dial-peer can be matched inbound only

      incoming called-number 5310.  

 !--DNIS range 53100-53109 

      direct-inward-dial  

 !--If this dial-peer is matched inbound, the router is put in DID mode

     !
     dial-peer voice 4 pots 

 !--This dial-peer can be matched inbound only

      incoming called-number 5311.   

 !--This takes care of the range 53110-53119

      direct-inward-dial 

 !--If this dial-peer is matched inbound router is put in DID mode

     !
     dial-peer voice 5 voip  

 !--For our case, this dial-peer is matched outbound only 

      destination-pattern 53... 

 !--When calls terminate on this router, dial-peer 5 can be matched inbound, too.

      session target ipv4:172.22.1.1 

 !--IP address of CallManager

      codec g711ulaw 

المشكلات الشائعة

ملاحظة: تتضمن أكواد أسباب قطع الاتصال تنسيقات مختلفة في إخراج الأمر debug isdn q931 بدلا من الأمر debug voip ccapi inout.

• لترجمة إستدعاءات Q.931 قطع الاتصال برموز السبب من تسجيل الوارد ل debug voIP راجع: أستكشاف الأخطاء وإصلاحها وتصحيح أخطاء إستدعاءات VoIP - الأساسيات

• لترجمة رموز سبب قطع اتصال المكالمة Q.931 من debug isdn q931 ارجع إلى: فهم تصحيح الأخطاء ISDN q931 أكواد سبب قطع الاتصال

لعرض أكواد سبب حدث Q.931 بتنسيق عشري، ارجع إلى: أكواد سبب حدث ISDN

وفيما يلي بعض الأمثلة على الأعراض والمسائل التي قد تسببها:

• العرض: يوفر الموجه/البوابة نغمة الطلب وينتظر حتى ينتهي المؤقت بين الخانات. ثم ينقطع الاتصال برمز السبب debug voip ccapi inout = 0x1C (تنسيق رقم غير صالح) أو debug isdn q931 (لواجهات ISDN) يقوم بفصل رمز السبب = 0x809C (تنسيق رقم غير صالح).

  • الإصدار: تم تكوين DID على محول Telco ولكن ليس على موجه/بوابة Cisco IOS.

• العرض: ينفصل الموجه/البوابة عن رمز السبب debug voip ccapi = 0x1 (رقم غير مخصص/غير معين) أو debug isdn q931 (لواجهات ISDN) يقوم بفصل رمز السبب = 0x8081 (رقم غير مخصص/غير معين).

  • الإصدار: تم تكوين DID وتمت مطابقة نظير طلب POTS الوارد الصحيح على موجه/عبارة Cisco IOS، ولكن رسالة الإعداد لا تتضمن إستدعاء-number (DNIS). في هذه الحالة، تحقق من خلال telco أن خط الاتصال تم توفيره ل DID.

• العرض: قطع الموجه/البوابة الاتصال برمز السبب debug voip ccapi = 0x1 (رقم غير مخصص/غير معين) أو debug isdn q931 (لواجهات ISDN) قطع اتصال رمز السبب = 0x8081 (رقم غير مخصص/غير معين).

  • الإصدار: تم تكوين DID ومطابقته على موجه/بوابة Cisco IOS، ولكن لا يوجد تطابق طلب-نظير صادر على الموجه/البوابة.

  • الإصدار: تأكد من تطابق المكالمة الواردة مع طلب نظير POTS الصحيح حيث تم تكوين الأمر direct-inward-dial. لمزيد من المعلومات، ارجع إلى قسم مطابقة نظير طلب POTS الوارد الصحيح ل DID في هذا المستند

إخراج show و debug للعينة

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

2600#debug isdn q931
ISDN Q931 packets debugging is on
2600#debug voip ccapi inout
voip ccAPI function enter/exit debugging is on

2600#show debug
ISDN:
  ISDN Q931 packets debugging is on
  ISDN Q931 packets debug DSLs. (On/Off/No DSL:1/0/-)
  DSL  0 --> 31
  1 - - - - - - -  - - - - - - - -  - - - - - - - -  - - - - - - - -  
voip:
  voip ccAPI function enter/exit debugging is on


!--- Action: Cisco IOS router/gateway receives a call from the PSTN to !--- extension "53103"

*Mar  1 04:51:11.856: ISDN Se1/0:23: RX <-  SETUP pd = 8  callref = 0x0001
*Mar  1 04:51:11.860:         Bearer Capability i = 0x9090A2
*Mar  1 04:51:11.860:         Channel ID i = 0xA98381
*Mar  1 04:51:11.864:         Calling Party Number i = 0x0083, '408', Plan:Unknown,
      Type:Unknown
*Mar  1 04:51:11.868:         Called Party Number i = 0x80, '53103', Plan:Unknown,
      Type:Unknown

!--- ISDN Q.931 and Voip ccapi inout debugs collectively show a DNIS of 53103 and !--- an ANI (Automatic Number Identification) of 408 sent in unknown plan and type.


*Mar  1 04:51:11.880: cc_api_call_setup_ind (vdbPtr=0x831721D8, callInfo=
        {called=53103,called_oct3=0x80,calling=408,calling_oct3=0x0,
        calling_oct3a=0x83, calling_xlated=false,subscriber_type_str=RegularLine,
        fdest=1,peer_tag=3, prog_ind=0},callID=0x83349DF8)
*Mar  1 04:51:11.884: cc_API_call_setup_ind type 13 , prot 0
*Mar  1 04:51:11.888: cc_process_call_setup_ind (event=0x83149130)
*Mar  1 04:51:11.888: >>>>CCAPI handed cid 41 with tag 3 to app "DEFAULT"

!--- POTS dial-peer 3 was matched inbound


*Mar  1 04:51:11.888: sess_appl: ev(24=CC_EV_CALL_SETUP_IND), cid(41), disp(0)
*Mar  1 04:51:11.888: sess_appl: ev(SSA_EV_CALL_SETUP_IND), cid(41), disp(0)
*Mar  1 04:51:11.888: ssaCallSetupInd 
*Mar  1 04:51:11.892: ccCallSetContext (callID=0x29, context=0x83303C00)

!--- The POTS leg is created and assigned a callid of 0x29


*Mar  1 04:51:11.892: ssaCallSetupInd cid(41), st(SSA_CS_MAPPING),oldst(0), 
      ev(24)ev->e.evCallSetupInd.nCallInfo.finalDestFlag = 1
*Mar  1 04:51:11.892: ssaCallSetupInd finalDest cllng(408), clled(53103)

!--- Due to the direct-inward-dial config under dial-peer 3, the DNIS sent in !--- the setup request is considered sufficient to match an outbound dial-peer. !--- This is clear with flag set to 1. 


*Mar  1 04:51:11.892: ssaCallSetupInd cid(41), st(SSA_CS_CALL_SETTING),oldst(0),
      ev(24)dpMatchPeersMoreArg result= 0
*Mar  1 04:51:11.892: ssaSetupPeer cid(41) peer list:  tag(5) called number (53103) 

!--- Dial-peer table lists only dial-peer 5 as matched outbound against the DNIS.


*Mar  1 04:51:11.892: ssaSetupPeer cid(41), destPat(53103), matched(2), 
      prefix(), peer(83369DB8), peer->encapType (2)

!--- Due to destination-pattern having 2 digits and 3 dots, explicit match is !--- reported as 2.


*Mar  1 04:51:11.896: ccCallProceeding (callID=0x29, prog_ind=0x0)
*Mar  1 04:51:11.896: ccCallSetupRequest (Inbound call = 0x29, outbound peer =5,
      dest=, params=0x831578C0 mode=0, *callID=0x83157C28, prog_ind = 0)
*Mar  1 04:51:11.896: ccCallSetupRequest numbering_type 0x80
*Mar  1 04:51:11.896: dest pattern 53..., called 53103, digit_strip 0
*Mar  1 04:51:11.896: callingNumber=408, calledNumber=53103, redirectNumber=
      display_info= calling_oct3a=83

!--- Just before matching an outbound dial-peer, we remember that we have !--- seen the same ANI and DNIS in the ISDN setup and in the ccapi debug initially. !--- In other words, the router did not collect additional digits after the seizure. !--- Equal value of DNIS at setup request and before matching an outbound !--- dial-peer is the whole purpose of DID


*Mar  1 04:51:11.896: accountNumber=, finalDestFlag=1,
      guid=c66d.980c.17a8.0051.0000.0000.010a.998a
*Mar  1 04:51:11.896: peer_tag=5
*Mar  1 04:51:11.896: ccIFCallSetupRequestPrivate: (vdbPtr=0x824C6344, dest=, 
      callParams={called=53103,called_oct3=0x80, calling=408,calling_oct3=0x0, 
      calling_xlated=false,subscriber_type_str=RegularLine, fdest=1,
      voice_peer_tag=5},mode=0x0) vdbPtr type = 3
*Mar  1 04:51:11.900: ccIFCallSetupRequestPrivate: (vdbPtr=0x824C6344, dest=,
      callParams={called=53103, called_oct3 0x80,  calling=408,calling_oct3 0x0, 
      calling_xlated=false,  fdest=1, voice_peer_tag=5}, mode=0x0, xltrc=-5)
*Mar  1 04:51:11.900: ccSaveDialpeerTag (callID=0x29, dialpeer_tag=
*Mar  1 04:51:11.900: ccCallSetContext (callID=0x2A, context=0x8330408C)
*Mar  1 04:51:11.900: ccCallReportDigits (callID=0x29, enable=0x0)
*Mar  1 04:51:11.904: cc_API_call_report_digits_done (vdbPtr=0x831721D8,
      callID=0x29, disp=0)
*Mar  1 04:51:11.904: sess_appl: ev(52=CC_EV_CALL_REPORT_DIGITS_DONE),
      cid(41), disp(0)
*Mar  1 04:51:11.904: cid(41)st(SSA_CS_CALL_SETTING)ev
      (SSA_EV_CALL_REPORT_DIGITS_DONE)
oldst(SSA_CS_MAPPING)cfid(-1)csize(0)in(1)fDest(1)
.

!--- Output Omitted

.

!--- The following output displays the Call is finished


*Mar  1 04:51:52.442: ISDN Se1/0:23: RX <-  DISCONNECT pd = 8  callref = 0x0001
*Mar  1 04:51:52.442:         Cause i = 0x8290 - Normal call clearing
*Mar  1 04:51:52.458: ISDN Se1/0:23: TX ->  RELEASE pd = 8  callref = 0x8001
*Mar  1 04:51:52.458: cc_API_call_disconnected(vdbPtr=0x831721D8, callID=0x29,
      cause=0x10)
*Mar  1 04:51:52.462: sess_appl: ev(11=CC_EV_CALL_DISCONNECTED), cid(41), disp(0)
*Mar  1 04:51:52.462: cid(41)st(SSA_CS_ACTIVE)ev(SSA_EV_CALL_DISCONNECTED)
      oldst(SSA_CS_ACTIVE)cfid(9)csize(2)in(1)fDest(1)
*Mar  1 04:51:52.462: -cid2(42)st2(SSA_CS_ACTIVE)oldst2(SSA_CS_ALERT_RCVD)
*Mar  1 04:51:52.462: ssa: Disconnected cid(41) state(5) cause(0x10)
*Mar  1 04:51:52.462: ccConferenceDestroy (confID=0x9, tag=0x0)
*Mar  1 04:51:52.462: cc_API_bridge_drop_done (confID=0x9, srcIF=0x824C6344, 
      srcCallID=0x2A, dstCallID=0x29, disposition=0 tag=0x0)
*Mar  1 04:51:52.466: cc_API_bridge_drop_done (confID=0x9, srcIF=0x831721D8, 
      srcCallID=0x29, dstCallID=0x2A, disposition=0 tag=0x0)
*Mar  1 04:51:52.466: sess_appl: ev(30=CC_EV_CONF_DESTROY_DONE), cid(41), disp(0)
*Mar  1 04:51:52.470: cid(41)st(SSA_CS_CONF_DESTROYING)ev(SSA_EV_CONF_DESTROY_DONE)
      oldst(SSA_CS_ACTIVE)cfid(-1)csize(2)in(1)fDest(1)
*Mar  1 04:51:52.470: -cid2(42)st2(SSA_CS_CONF_DESTROYING)oldst2(SSA_CS_ALERT_RCVD)
*Mar  1 04:51:52.470: ssaConfDestroyDone 
*Mar  1 04:51:52.470: ccCallDisconnect (callID=0x29, cause=0x10 tag=0x0)
*Mar  1 04:51:52.470: ccCallDisconnect (callID=0x2A, cause=0x10 tag=0x0)


!--- These two lines are great for finding the source of the disconnect. !--- They tell us that the first call leg with callid 0x29 (POTS call leg) !--- disconnected with cause code 0x10. So either the end POTS user hung up or the !--- telephony equipment disconnected unintentionally. From the router's point of !--- view, both are the same.


*Mar  1 04:51:52.470: ISDN Se1/0:23: RX <-  RELEASE_COMP pd = 8  callref = 0x0001
*Mar  1 04:51:52.499: cc_API_call_disconnect_done(vdbPtr=0x831721D8, callID=0x29,
      disp=0, tag=0x0)


!--- Debug truncated here
 


2600#show call active voice brief 

!--- This show command is good to verify which are the dial-peers matched by the !--- call. In the example below, the output show the POTS call-leg matched !--- dial-peer voice 3 pots (pid:3) the VoIP call-leg matched !--- dial-peer voice 5 voip (pid:5). !--- some output omitted


Total call-legs: 2
3A   : 799622hs.1 +112 pid:3 Answer 408 active
 dur 00:00:07 tx:385/61600 rx:160/23690
 Tele 1/0:23:33: TX:7730/3060/0ms g711ulaw noise:-42 acom:0  i/0:-43/-53 dBm

3A   : 799625hs.1 +106 pid:5 Originate 53103 active
 dur 00:00:07 TX:160/23690 rx:385/61600
 IP 171.68.168.250:25704 rtt:0ms pl:4980/0ms lost:0/0/0 delay:64/64/65ms g711ulaw