Голосовая связь : H.323

Обработка префиксов зоны с точками в сравнении с обработкой префиксов со звездочками

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв


Содержание


Введение

В данном документе описывается проблема, которую испытывают некоторые сетевые разработчики с использованием точек в качестве подстановочных символов в префиксах зоны. Это тогда представляет общее решение этой проблеме путем предложения использования, если это возможно, звездочки (" * ") подстановочные знаки вместо этого. Наконец, этот документ проясняет логику зональной обработки со специальной ссылкой на различия между двумя методами настройки групповых символов.

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

Требования

Читатели данной документации должны быть хорошо осведомлены относительно потоков H.323 и понятий Сторожевого устройства Cisco в определенной зональной обработке. Обратитесь к Пониманию Маршрутизации вызова Сторожевого устройства Cisco IOS и Сторожевых устройств H.323 Настройки и Прокси для получения дополнительной информации о Сторожевом устройстве Cisco и зональной обработке. Первый из этих документов полезен для понимания обработки зоны сторожевого устройства.

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

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

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

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

Проблема

Основная причина беспорядка, отнесенного к использованию точек и звездочек, находится в поведении по умолчанию сторожевого устройства при обработке префиксов. Этот режим работы, подробно описанный в разделе "Объяснение характеристик обработки стандартного кода зоны для привратника" данного документа, может создавать неоднозначные ситуации, если в плане соединений присутствует перекрытие, и конфигурации приходится использовать обе точки и звездочки.

Симптомы и характеристики проблемы таковы:

  • Локальное сторожевое устройство, как ожидают, направит вызовы к нескольким локальным зонам или, как ожидают, направит вызовы к сторожевым устройствам в удаленных зонах или обоих.

  • Вызовы внутри локальной зоны успешно маршрутизируются.

  • Некоторые, но не все, межзональные вызовы могут маршрутизироваться успешно.

  • Межзональные вызовы, которые не маршрутизируются успешно, к вызываемым номерам с определенным количеством цифр. Например, в то время как вызов к трехзначному числу начиная с той же цифры надежно отказывает, вызовы к 10-разрядному или девятиразрядному количеству могут успешно выполниться.

  • Конфигурация сторожевого устройства использует точечные подстановочные знаки в префиксах зоны.

Решение

Когда вы задаете специальные символы в префиксе зоны, избегаете использования точек, если это возможно. Вместо этого используйте менее подробный подстановочный знак звездочки. Когда вы наблюдаете эти правила, можно также избежать проблемы:

  1. Если план соединений является непротиворечивым, можно использовать конфигурацию с только точками (или использование только звездочек).

  2. Если в плане телефонных соединений есть перекрытие, лучше всего использовать конфигурации со звездочками (*).

  3. Если существует наложение в плане соединений, и конфигурация с только звездочками не подходит, учитесь, поведение по умолчанию сторожевого устройства определения префикса (выведите и предварительно ожидайте код локальной области) перед настройкой сторожевого устройства.

Третье правило требует понимания подробных данных поведения сторожевого устройства, как описано в этом документе.

Объяснение характеристик обработки стандартного кода зоны для привратника

Данный пример иллюстрирует поведение сторожевого устройства, когда это обрабатывает запрос вызова в форме Запроса на доступ (ARQ) от оконечной точки H.323. Шаги 2 и 3 являются ключевыми для области этого документа. Можно шагнуть через эту блок-схему позже в документе со ссылкой на отладку в качестве примера: Неудачный вызов.

/image/gif/paws/23900/zone_pre_process_dots_asterisks-1.gif

Обработка префикса зоны немного отличается, чем обработка префикса получателя. Когда вы совпадаете с префиксами зоны, Сторожевое устройство Cisco предпринимает специальную попытку квалифицировать зону кодом зоны, если это возможно. Если с вызываемым номером совпадают в локальной зоне, сторожевое устройство выводит, что код локальной области (префикс вызывающего номер) должен предварительно ожидаться к вызываемому номеру.

Например, ARQ поступает на привратник с вызывающим номером "415xxxxxxx" (415 – код области).

Сторожевое устройство имеет 415 зон, настроенных как поддерживающий префикс "415......." (семь точек). Из-за этой записи, если вызываемый номер 5551212 (в частности семь цифр) тогда, сторожевое устройство предварительно ожидает его с тем же префиксом как вызывающий номер. Таким образом, вызываемый номер, который нужно обработать – это номер 4155551212 в локальной зоне.

Примечание: По количеству точек в зоне префикса команды определяется соответствие набранного номера локальной зоне. В вышеупомянутом, шестизначное число (например: 555123), не совпадает с настроенным префиксом зоны "415......." (семь точек). Поэтому вызываемый номер не выведен, чтобы быть 415555123, но остается 555123 и совпадает с префиксом зоны "555*".

Однако, если локальная зона настроена как "415*", и конфигурация также включает зону по умолчанию X, который обрабатывает "*", тогда, когда спросили решить адрес 5551212, процессы шлюза ARQ как совпадающий в зоне X, если X другая зона на локальном сторожевом устройстве или передает Запрос местонахождения (LRQ) к X, если это - удаленная зона.

Это - пример, который иллюстрирует понятие со ссылкой на соответствующий Cisco фрагменты конфигурации IOS�.

Префикс поведения зоны с точками или звездочками вЂ" Фрагменты конфигурации привратника

!--- 5551212 is the called number 
!--- and the request comes into zone localzone2.
!--- It is important to know that the calling number has prefix 415.  

zone prefix localzone2 415.......
zone prefix localzone1 555*

!--- In this case, this line is what the match is with.

Zone prefix localzone2 415.......

!--- The match is due to these reasons:


!--- 1. The calling number begins with 415.
!--- 2. There is a local wildcard entry for 415 with seven dots. This entry
!--- causes the gatekeeper to assume that the the seven-digit called
!--- number is local and therefore expands 5551212 to 4155551212 by 
!--- prepending the area code of the calling number. This expanded
!--- number matches, and the call will be accepted or rejected based on
!--- the registered resources, in localzone2.


!--- If the configuration is changed, as shown here, then there is no
!--- expansion of the number (because there is no seven-dot entry). 

zone prefix localzone2 415*
zone prefix localzone1 555*

!---  This line is what the match is now with.

Zone prefix localzone1 555* 

!--- In this case, the call is accepted or rejected based on registered
!--- resources in localzone1.

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

Примечание: Этот пример практического применения использует одно сторожевое устройство с двумя локальными зонами. Те же принципы применяются к дизайнам нескольких сторожевых устройств, где локальное сторожевое устройство настроено, чтобы передать LRQ удаленным сторожевым устройствам зоны.

Эта схема показывает упрощенное представление зоны H.323 "новой мировой" сети поставщика услуг. В данной сети обеспечивается передача голоса по IP-сетям (VoIP) между клиентами H.323 в зоне localzone2, а также доступ этих клиентов к телефонной сети общего пользования (PSTN). Магистральные шлюзы (TGW), обеспечивающие доступ к PSTN, находятся в отдельной зоне, называемой localzone1.

zone_pre_process_dots_asterisks-2.gif

Примечание: Клиенты H.323 могут или быть собственными пользователями IP-телефонии H.323, простыми адаптерами аналога H.323, такими как Cisco ATA или другие подобные продукты стороннего разработчика или шлюзы более крупного масштаба. Поддержка дизайнов шлюза более крупного масштаба, особенно те с удаленными пользователями Телефонии, вероятно повлекла бы за собой более сложную зональную структуру, чем, что обсуждено в этом примере практического применения. Кроме того, эти 5350 TGW могут предоставить доступ к тфоп через цифровые соединения E1/T1, такие как Primary Rate ISDN или Сигнализация по выделенному каналу (CAS). Они также могут предоставить прямое соединение SS7 использованием подходящего агента вызовов SS7, такого как Cisco SC2000 или PGW2200.

команды configuration и show

Связанные со сторожевым устройством команды, установленные на сторожевом устройстве, показывают здесь. Линии в конфигурации, которые выделены, являются значительными в более поздней демонстрации проблемы с, в этом случае, трехразрядные номера телефона, где вызов предпринят от localzone2 до localzone1.

Конфигурация сторожевого устройства (сторожевое устройство дает команду только),
gatekeeper
  zone local localzone1 dns.au 10.1.1.228
  zone local localzone2 dns.au
  no zone subnet localzone1 default enable
  zone subnet localzone1 10.1.1.240/28 enable
  no zone subnet localzone2 default enable
  zone subnet localzone2 10.99.0.0/16 enable
  zone prefix localzone1 0*
  zone prefix localzone1 1*
  zone prefix localzone1 6*
  zone prefix localzone1 8*
  zone prefix localzone2 9999931..
  Zone prefix localzone2 9999932..
  Zone prefix localzone2 9999933..
  Zone prefix localzone2 9999934..
  Zone prefix localzone2 9999935..
  Zone prefix localzone2 9999936..
  Zone prefix localzone2 9999937..
  Zone prefix localzone2 9999938..
  Zone prefix localzone2 9999939..
  Zone prefix localzone2 999994...
  zone prefix localzone2 999995...
  zone prefix localzone1 9*
  accounting vsa
  gw-type-prefix 1#* default-technology
  arq reject-unknown-prefix
  lrq reject-unknown-prefix
  no use-proxy localzone2 default inbound-to terminal
  no use-proxy localzone2 default outbound-from terminal
  no shutdown
  endpoint ttl 60

Эти выходные данные команды show gatekeeper endpoints показывают оконечные точки H.323, зарегистрированные в сторожевом устройстве вместе с зонами, в которых они зарегистрированы.

Примечание: В то время как терминалы H.323 зарегистрированы в localzone2, TGW зарегистрировались правильно к сторожевому устройству в localzone1.

show gatekeeper endpoints
GK#show gatekeeper endpoints 
GATEKEEPER ENDPOINT REGISTRATION
================================
CallSignalAddr  Port  RASSignalAddr   Port  Zone Name     Type Flags
--------------- ----- --------------- ----- ---------     ---- -----
10.99.0.10      1720  10.99.0.10      45690 localzone2    TERM E164-ID: 999995988
10.99.0.11      1720  10.99.0.11      29249 localzone2    TERM E164-ID: 999995981
10.99.0.12      1720  10.99.0.12      19227 localzone2    TERM E164-ID: 999995985
10.99.0.15      1720  10.99.0.15      36889 localzone2    TERM E164-ID: 999995989
10.99.0.16      1720  10.99.0.16      42366 localzone2    TERM E164-ID: 999995982
10.99.0.18      1720  10.99.0.18      18300 localzone2    TERM E164-ID: 999995986
10.99.0.19      1720  10.99.0.19      32345 localzone2    TERM E164-ID: 999995980
10.99.0.20      1720  10.99.0.20      23155 localzone2    TERM E164-ID: 999995984
10.1.1.240      1720  10.1.1.240      50737 localzone1    VOIP-GW H323-ID: tgw1@dns.au
10.1.1.241      1720  10.1.1.241      50737 localzone1    VOIP-GW H323-ID: tgw2@dna.au
Total number of active registrations = 10

Эти выходные данные команды show gatekeeper zone prefix правильно указывают на зону, к которой должны маршрутизироваться соответствующие префиксы E.164.

show gatekeeper zone prefix
ZRZ-GK1#show gatekeeper zone prefix
	    ZONE PREFIX TABLE
            =================
GK-NAME               E164-PREFIX
-------               -----------
localzone1            0*
localzone1            1*
localzone1            6*
localzone1            8*
localzone2            9999931..
localzone2            9999932..
localzone2            9999933..
localzone2            9999934..
localzone2            9999935..
localzone2            9999936..
localzone2            9999937..
localzone2            9999938..
localzone2            9999939..
localzone2            999994...
localzone2            999995...
localzone1            9*

Эти выходные данные команды show gatekeeper gw-type-prefix показывают технические префиксы, настроенные для этого сторожевого устройства.

Заметьте, что только tech-prefix по умолчанию (1#) настроен на сторожевом устройстве. Кроме того, только 5350 TGW (tg1 и tgw2) в зоне localzone1 настроены для регистрации с этим технологическим префиксом по умолчанию.

show gatekeeper gw-type-prefix
GK#show gatekeeper gw-type-prefix 
GATEWAY TYPE PREFIX TABLE
=========================
Prefix: 1#*    (Default gateway-technology)
  Zone localzone1 master gateway list:
    10.1.1.240:1720 tgw1 
    10.1.1.241:1720 tgw2 (out-of-resources)

Отладка и детальное обсуждение

Это - выходные данные отладки от сторожевого устройства, которое показывает Протокол регистрации, входа и состояния (RAS) потоки и обработка префикса зоны для:

Он содержит подробный комментарий, в котором объясняется поведение привратника во время обработки символа подстановки точки в префиксах зон и сравнивается с обработкой символа подстановки звездочки.

debug h225 asn1 and debug gatekeeper main 10 - failed call
GK#show debug
gk main debug level = 10
H.225: H.225 ASN1 Messages debugging is on

!--- This output is from the debug h225 ans1 command issued on the gatekeeper. It shows 
!--- an incoming RAS ARQ for called number 112. It is important to
!--- note that the calling number (source endpoint) comes from the zone localzone2 and,
!--- assuming three-digit numbers, its prefix (source endpoint prefix) is 999995.
  
Mar 11 21:48:15: RAS INCOMING PDU ::=

value RasMessage ::= admissionRequest : 
    {
      requestSeqNum 36784
      callType pointToPoint : NULL
      callModel gatekeeperRouted : NULL
      endpointIdentifier {"618FED9800000008"}
      destinationInfo 
      {
        e164 : "112",
        e164 : "112"
      }
      srcInfo 
      {
        h323-ID : {"999995985"},
        e164 : "999995985"
      }
      srcCallSignalAddress ipAddress : 
      {
        ip '0A14000C'H
        port 11309
      }
      bandWidth 1280
      callReferenceValue 31633
      conferenceID '5634343434EF21002B211E5226E91D26'H
      activeMC FALSE
      answerCall FALSE
      canMapAlias FALSE
      callIdentifier 
      {
        guid '5634343434EF20002B211E5226E91D26'H
      }
      gatekeeperIdentifier {"localzone2"}
      willSupplyUUIEs FALSE
    }

!--- This output is from the debug gatekeeper main 10 command 
!--- issued on the gatekeeper. It 
!--- shows the gatekeeper zone prefix processing logic (rassrv_get_addrinfo). 
!--- Comments are inserted throughout. 

Mar 11 21:48:15: gk_rassrv_arq: arqp=0x61A09EE4, crv=0x7B91, answerCall=0
Mar 11 21:48:15: ARQ Didn't use GK_AAA_PROC

!--- Tech-prefix matching occurs first. In this case study, no
!--- tech-prefixes are configured so no match is found. 

Mar 11 21:48:15: rassrv_get_addrinfo(112): Tech-prefix match failed.

!--- The next line in the trace is the key to what, in this case study, is unexpected 
!--- behavior. The expected behavior is for 112 to match with the wildcard "1*" entry 
!--- in localzone1. 

!--- The local (source) zone of the calling number is localzone2. 
!--- It has been configured as 
!--- supporting the prefix "999995..." with three wildcard digits. 
!--- (Note the configuration line 
!--- "zone prefix localzone2 999995...".)

!--- The gatekeeper, when asked to resolve a three-digit number 112, 
!--- deduces this to mean "999995-112" in the local zone because 
!--- "112" matches with the specific-length three-dot 
!--- wildcard configuration for the local zone. 

!--- This behavior is exactly the same as a local area code being assumed when a local 
!--- call is made. 



!--- If the configuration line "zone prefix localzone2 999995..." was removed from the 
!--- configuration, or if the line "zone prefix localzone2 999995*" was inserted instead,
!--- then the three-digit number "112" would not match in the local 
!--- zone but would rather match localzone1 through the 
!--- configuration line "zone prefix localzone1 1*".

Mar 11 21:48:15: rassrv_get_addrinfo(112): Defaulting to source endpoint's zone prefix 999995

Mar 11 21:48:15: No tech-prefix

Mar 11 21:48:15: Alias not found

!--- The gatekeeper attempts to find a default technology prefix, But although "#1" is 
!--- configured, the H.323 endpoints in localzone2 correctly do not register with that. The
!--- conclusion drawn is that there is an "unknown address and no default 
!--- technology defined":

Mar 11 21:48:15: rassrv_get_addrinfo(112): default-tech gateway selection failed, status = 0x805
Mar 11 21:48:15: rassrv_get_addrinfo(112): unknown address and no default technology defined.
Mar 11 21:48:15: rassrv_get_addrinfo(112): Tech-prefix match failed.
Mar 11 21:48:15: rassrv_get_addrinfo(112): Defaulting to source endpoint's zone prefix 999995
Mar 11 21:48:15: No tech prefix

Mar 11 21:48:15: Alias not found

!--- The gatekeeper indicates that it has failed to find a registered match for the  
!--- called number in localzone2:

Mar 11 21:48:15: rassrv_get_addrinfo(112): default-tech gateway selection failed, status = 0x805
Mar 11 21:48:15: rassrv_get_addrinfo(112): unknown address and no default technology defined.
Mar 11 21:48:15: gk_rassrv_sep_arq(): rassrv_get_addrinfo() failed (return code = 0x103)

!--- The gatekeeper sends the Admission Reject (ARJ) because the called party is not 
!--- registered:

Mar 11 21:48:15: RAS OUTGOING PDU ::=

value RasMessage ::= admissionReject : 
    {
      requestSeqNum 36784
      rejectReason calledPartyNotRegistered : NULL
    }

Эта отладка является извлечением из выходных данных команды debug gatekeeper main 10 и показывает успешный вызов.

debug gatekeeper main 10 – успешный вызов
GK#show debug
gk main debug level = 10
H.225: H.225 ASN1 Messages debugging is on

!--- The four-digit called number 1003 does not match with the three-dot wildcard 
!--- for localzone2 noted earlier. Instead, it matches with the less-specific 
!--- asterisk wildcard for localzone1.

Feb 19 16:52:19: rassrv_get_addrinfo(1003): Tech-prefix match failed.
Feb 19 16:52:19: rassrv_get_addrinfo(1003): Matched zone prefix 1 and remainder 003
Feb 19 16:52:19: No tech prefix
Feb 19 16:52:19: Alias not found

!--- The gatekeeper finds a default technology prefix (of #1) since the 5350
!--- TGWs register with this prefix as per the 
show gatekeeper gw-type-prefix
 command.

Feb 19 16:52:19: Technology GW selected

Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


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


Document ID: 23900