Голосовая связь : Digital CCS

Общие сведения о прямом входном наборе (DID) на цифровых голосовых интерфейсах (T1/E1) Cisco IOS

20 октября 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Перевод, выполненный профессиональным переводчиком (8 февраля 2010) | Английский (22 августа 2015) | Отзыв


Содержание


Введение

Эти технические примечания применимы к маршрутизаторам или шлюзам Cisco IOS с поддержкой голосовой связи и наличием цифровых интерфейсов (T1/E1). Для получения дополнительной информации об аналоговом прямом входящем наборе (DID) Cisco обратитесь к документу: Аналоговый прямой входящий набор (DID) для маршрутизаторов Cisco серии 2600 и Cisco серии 3600

Примечание: На большинстве платформ DID включен по умолчанию на CAS (непосредственный, подмигивание, задержка) интерфейсы. Таким образом, не следует настраивать команду "direct-inward-dial" для входящих вызовов. На платформах Cisco AS5300 DID не поддерживается на интерфейсах, настроенных для безотлагательной сигнализации E & M.

Предварительные условия

Требования

Для этого документа отсутствуют особые требования.

Используемые компоненты

Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования.

Условные обозначения

Дополнительные сведения об условных обозначениях в документах см. Cisco Technical Tips Conventions.

Общие сведения

DID (прямой входной набор) — это услуга, предлагаемая телефонными компаниями, которая позволяет абонентам напрямую вызывать добавочный номер на УАТС или в системе передачи речевых пакетов без помощи оператора или автосекретаря. Для обеспечения функционирования подобной услуги используются магистрали DID, которые передают только последние 3–5 цифр телефонного номера на УАТС или маршрутизатор/шлюз. Например, если компания использует добавочные номера с 555-1000 до 555-1999 и абонент вызывает номер 555-1234, местный центральный офис переадресует 234 на УАТС или в систему передачи голосовых пакетов. Затем УАТС или система передачи голосовых пакетов (Cisco CallManager и маршрутизатор/шлюз IOS) вызовет добавочный номер 234. Этот процесс проходит незамеченным для пользователя.

В этом документе обсуждаются следующие два типа одноранговых телефонных соединений:

  • PlainOld Telephone Service (POTS) (обычная телефонная сеть) — Это - традиционный голосовой вызов, размещенный по Открытой коммутируемой телефонной сети (PSTN), где вы получаете выделенную ветвь сквозного вызова в сети со скоростью 64 кбит/с во время продолжительности вызова. Одноранговые телефонные соединения обычной телефонной сети всегда указывают на голосовой порт маршрутизатора

  • Голосовая сеть — голосовой вызов по сети передачи данных составлен из нескольких участков вызова. Каждый участок вызова перемещается между устройствами данных (маршрутизаторы/шлюзы) или между устройствами данных и телефонными устройствами (например, маршрутизатором и УАТС). Одноранговые телефонные соединения Voice-Network указывают на различные места назначения в зависимости от используемой сетевой технологии. Одноранговые телефонные соединения голосовой сети включают следующие типы:

    • Передача голоса по IP (VoIP)

    • Технология Voice over Frame Relay (VOFR)

    • Передача голоса по ATM (VoATM)

    • Мультимедийная почта поверх IP (MMoIP)

Когда телефонный вызов поступает на маршрутизатор/шлюз Cisco IOS, входящий трафик голосового порта на маршрутизаторе перехватывается УАТС или коммутатором центрального офиса. После этого маршрутизатор/шлюз передаст абоненту тональный сигнал и будет собирать данные о номере (цифры) до идентификации исходящей адресуемой конечной точки вызова. Вне зависимости от того, набираются цифры человеком с нерегулярными интервалами или стандартным телефонным оборудованием, отсылающим заранее набранные цифры, согласование однорангового телефонного соединения происходит детально, цифра за цифрой. Это означает, что маршрутизатор/шлюз пытается сопоставить одноранговое телефонное соединение после каждой полученной цифры. Этот процесс называется двухэтапным набором.

Однако если УАТС или коммутатор центрального офиса отправляет сообщение настройки, содержащее «все» цифры, необходимые для полной маршрутизации вызова, эти цифры можно сопоставить непосредственно исходящему одноранговому телефонному соединению голосовой сети. При использовании DID маршрутизатор/шлюз не генерирует для вызывающего абонента тональный сигнал и не запоминает цифры. Он направляет вызов непосредственно по указанному назначению. Это называется одноступенчатым соединением.

Далее представлены два типа цифр, необходимых для маршрутизации вызовов, которые обсуждались выше:

  • Digital Number Identification Service (DNIS) — это цифровая услуга, предоставляемая телефонными компаниями, с помощью которой передается вызываемый номер (набранный номер).

  • Automatic Number Identification (ANI) — это цифровая услуга, предоставляемая телефонными компаниями, с помощью которой передается вызывающий номер (номер звонящего абонента). ANI также называется автоматическим определителем номера.

Конфигурация DID для узлов ТфОП

При получении входящего вызова из обычной телефонной сети функция DID одноранговых телефонных соединений позволяет маршрутизатору/шлюзу использовать номер вызывающей стороны (DNIS) для непосредственного выбора исходящего однорангового телефонного соединения. Когда возможность DID настроена на входящей точке вызова POTS, набранный номер автоматически используется для сопоставления шаблона назначения для исходящего участка вызова.

Чтобы настроить одноранговое телефонное соединение обычной телефонной сети для DID, введите следующие команды Cisco IOS, начав в режиме глобальной конфигурации:

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

Сопоставление правильного входящего вызова для автоматического установления входящего соединения

Для правильного функционирования DID убедитесь, что входящие вызовы соответствуют нужному одноранговому телефонному соединению обычной телефонной сети, для которого настроена команда direct-inward-dial. Для сопоставления правильного входящего однорангового телефонного соединения рекомендуется использовать строку DNIS номера входящего вызова для однорангового соединения DID обычной телефонной сети (POTS).

Другие команды, используемые для обеспечения соответствия одноранговых телефонных соединений включают: ANI_string адреса для ответа , destination-pattern string или голосовой порт порта . Преимуществом использования команды incoming called-number является то, что каждый вызов имеет связанные сведения DNIS (вызываемый номер), а также то, что у данной команды есть приоритет над предыдущими командами.

Если не использовать команду incoming called-number для сопоставления входящего однорангового телефонного подключения, следует рассмотреть приведенные ниже факторы:

  • При использовании информации ANI для сопоставления однорангового телефонного соединения DID обычной телефонной сети убедитесь, что команда answer-address настроена правильно, а коммутатор телефонной компании предоставляет информацию ANI. Некоторые провайдеры ISDN и большая часть поканальной связанной сигнализации T1 (CAS), за исключением Feature Group D (fgd), не предоставляют никакой информации ANI.

  • Если адрес ответа НЕ сопоставляется с информацией ANI, информация ANI может сопоставляться с шаблоном назначения, настроенным (для исходящего набора) для другого однорангового телефонного соединения обычной телефонной сети. Если шаблон назначения противопоставлен ANI, убедитесь, что команда direct-inward-dial настроена для данного однорангового телефонного соединения.

  • Если входящий вызов DID не соответствует входящему вызову POTS, основанному на входящем набираемом номере, на адресе для ответов, на шаблоне назначения или на основе порта, то используется адресуемая точка вызова 0 по умолчанию. DID по умолчанию отключен для адресуемой точки вызова 0.

Примеры практического применения

Для иллюстрации указанных выше вопросов используется следующий пример. Компания ACME имеет каналы T1 PRI с 40 магистралями 40 в диапазоне от 555-3100 до 555-3139. Целью является назначить первые 20 линий IP-телефонам Cisco. Последние 20 линий доступны для тестирования и дальнейшего расширения. В настоящее время маршрутизатор выдает только тональный сигнал. Предполагая, что коммутатор центрального офиса передает только последние пять цифр сообщения установки ISDN, можно свести приведенные выше данные в следующую таблицу.

Набор номера пользователями PSTN Цифры, отправленные коммутатором на голосовой маршрутизатор/шлюз Использовать Кол-во магистралей
555-3100 к 555-3119 53100 - 53119 Линии DID для IP-телефонов 20
555-3120 – 555-3139 53120 - 53139 Тестирование и дальнейшее расширение 20

/image/gif/paws/14072/callmanager-gw.gif

!--- конфигурацию

Примечание: Некоторые выходные данные в этом примере пропущены.

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 в десятичном формате обращаются к: Коды причины события ISDN leavingcisco.com

Ниже приведены некоторые симптомы и их возможные причины:

  • Признак: Маршрутизатор/шлюз предоставляет тоновый сигнал и ожидает истечения срока ожидания межцифрового таймера. Затем он отключается по команде debugvoip ccapi inout с кодом причины 0x1C (недопустимый формат номера) или по команде debug isdn q931 (для интерфейсов ISDN) с кодом причины 0x809C (недопустимый формат номера).

    • Проблема: DID настроен на коммутаторе телефонной компании, но не на маршрутизаторе/шлюзе Cisco IOS.

  • Признак: Маршрутизатор/шлюз производит отключение по команде "debug voip ccapi inout" с кодом причины 0x1 (неразмещенный / неназначенный номер) или "debug isdn q931" (для ISDN-интерфейсов) с кодом причины отключения 0x8081 (неразмещенный / неназначенный номер).

    • Проблема: DID настроен, и допустимое входящее одноранговое телефонное соединение обычной телефонной сети сопоставляется на шлюзе/маршрутизаторе Cisco IOS, однако сообщение настройки не содержит вызванный номер (DNIS). В этом случае убедитесь, что в телефонной компании эта магистраль поддерживает DID.

  • Признак: Маршрутизатор/шлюз производит отключение по команде "debug voip ccapi inout" с кодом причины 0x1 (неразмещенный / неназначенный номер) или "debug isdn q931" (для ISDN-интерфейсов) с кодом причины отключения 0x8081 (неразмещенный / неназначенный номер).

    • Проблема: Служба DID настроена и согласована на маршрутизаторе/шлюзе Cisco IOS, но на маршрутизаторе/шлюзе отсутствует соответствующее одноранговое телефонное соединение.

    • Проблема: Убедитесь, что входящие вызовы соответствуют допустимому одноранговому телефонному соединению, для которого настроена команда direct-inward-dial. Для получения дополнительных сведений см. раздел "Соответствие адресуемой точки входящего вызова телефонной сети и DID" этого документа

Показ образца и данные отладки

Примечание: Некоторые из следующих отладочных строк разбиты на несколько строк для удобства печати.

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

Дополнительные сведения


Document ID: 14072