Перевод файла README.enum из Asterisk v1.2

2005-09-06

jtodd@loligo.com

Функция ENUMLOOKUP более комплексная чем это может показаться сначала, и это введение должно дать общий краткий обзор и некоторое количество примеров, которые могут более-менее подходить для продвинутого пользователя, чтобы оценить при их рассмотрении ENUM или ENUM-подобные cтратегии поиска. Этот документ дает знакомство с ENUM (RFC3761) или ENUM-подобными методами, а также знакомство с NAPTR записями DNS (RFC2915, RFC3401-3404).

Для ознакомления с NAPTR-записями, а также с использованием NAPTR в ENUM схеме отображения глобального номера телефона в DNS, для более подробной детализации, пожалуйста см. http://www.voip-info.org/tiki-index.php?page=ENUM

Использование ENUM в Asterisk может быть простое или комплексное, в зависимости от того, какие методы и процедуры повышению надежности Вы желаете использовать. Путь реализации ENUM должна определяться человеком, создающим записи NAPTR, но администратор локальной системы может игнорировать некоторые NAPTR ответы (вида URI) или предпочитать другие, что противоречит RFC. ENUMLOOKUP-метод просто обеспечивает администраторов способами для определения глобального уникального ENUM (e164.arpa) NAPTR-данных дерева DNS, или в других ENUM DNS деревьях, не имеющих глобальной уникальности. Способы фактического создания соединений ("наборы"), получаемые в результате работы функции ENUMLOOKUP, позволяют администратору выполнить его таким способом, который лучше всего подходит в данной ситуации.

Функция: ENUMLOOKUP([,pointer_type[,options[,zone_suffix]]])

Выполняет выполняет поиск в ENUM-дереве по точно указаному номеру, методу, а также с порядковым смещением (опционально), и возвращает одно из четырех различных значений:

1) после анализа NAPTR единственную схему (URI)

2) количество единичных схем (URI)

3) количество всех схем

4) Полную URI для конкретной схемы в списке всех возможных схем

Аргументы:

number = номер телефона или строка поиска. В этой строке анализируются только числовые символы; все другие символы при поиске игнорируются, но могут быть перезаписаны в случае повторного запроса расширеного регулярного выражения NAPTR

service_type = tel, sip, h323, iax2, mailto, ... [любая другая строка],

ALL. Заданный по умолчанию тип - "sip".

Специальное имя "ALL" задает создание списка типов схем по всем NAPTR-записей искомого номера, и затем результаты помещаются в упорядоченом списке, начинающемся с 1. Позиция точно установливается и будет затем возвращаться в списке, начинающимся с 1 в качестве первой записи (наименьшее значение). В Asterisk, за исключением значения по умолчанию (sip), сервисные типы закодированы не жестко, для таких случаев, когда точно не установлен никакой другой сервисный тип; схема типа "строка" (IANA-подтверждена или нет) может использоваться везде за исключением строки "ALL".

options = произвольные спецификаторы.

c = количество. Возвращается количество записей этого типа возврта (независимо от порядка или приоритета.) Если установлен service_type "ALL", то будет возвращено количество всех схем для DNS записей.

= запись приоритета/порядка последовательности, исходя из полного количества записей, возвращаемых после запроса. Если service_type определен, все входы того типа будут сортироваться в упорядоченный список, начиная с 1 (сначала по порядку, затем по приоритету).

По умолчанию значение - "1"

zone_suffix = устанавливает настройку зоны ENUM. Значение по умолчанию - e164. arpa.

Пример использования

Для примеров предлагается использовать список ENUM (необходимо отметить, что эти примеры существуют в DNS, и надеемся, останутся без изменений как примеры адресов, но со временем они могут измениться или стать неступными. Конечный результат URIs не гарантируется при реальной работы, так как некоторые из host-имен или SIP-proxi могут оказаться мнимыми. В частности, для "tel": ответы получены с помощью телефонных книг для Нью-Йорка и Сан-Франциско ...)

Также необходимо отметить, что для сложного SIP NAPTR в строке имеющей вес равный 30, необходимо удалит передачу "+" из строки набора, если он там будет. Возможно лучше такие NAPTR, чем жесткое кодирование номера в NAPTR, и это включено в более сложный реальный пример регулярного вырожения, хотя другой, более простой NAPTR будет работать точно также.

0.2.0.1.1.6.5.1.0.3.1.loligo.com. 3600 IN NAPTR 10 100 "u" "E2U+tel" "!^\\+13015611020$!tel:+12125551212!" .
0.2.0.1.1.6.5.1.0.3.1.loligo.com. 3600 IN NAPTR 21 100 "u" "E2U+tel" "!^\\+13015611020$!tel:+14155551212!" .
0.2.0.1.1.6.5.1.0.3.1.loligo.com. 3600 IN NAPTR 25 100 "u" "E2U+sip" "!^\\+13015611020$!sip:2203@sip.fox-den.com!" .
0.2.0.1.1.6.5.1.0.3.1.loligo.com. 3600 IN NAPTR 26 100 "u" "E2U+sip" "!^\\+13015611020$!sip:1234@sip-2.fox-den.com!" .
0.2.0.1.1.6.5.1.0.3.1.loligo.com. 3600 IN NAPTR 30 100 "u" "E2U+sip" "!^\\+*([^\\*]*)!sip:\\1@sip-3.fox-den.com!" .
0.2.0.1.1.6.5.1.0.3.1.loligo.com. 3600 IN NAPTR 55 100 "u" "E2U+mailto" "!^\\+13015611020$!mailto:jtodd@fox-den.com!" .

Пример 1: Самый простой случай, использующий первое возвращаемое SIP (используются все значения по умолчанию за исключением имени домена)
exten => 100,1,Set(foo=$ENUMLOOKUP(+13015611020,,,loligo.com))
возвращает: $foo="2203@sip.fox-den.com"

Пример 2: Какой первым указатель типа "tel" для этого номера? (После сортировки по порядку/ по приоритету; в области опций принято значение по умолчанию "1")
exten => 100,1,Set(foo=$ENUMLOOKUP(+13015611020,tel,,loligo.com))
возвращает: $foo="+12125551212"

Пример 3: Сколько имеется указателей типа "sip" для этого номера?
exten => 100,1,Set(foo=$ENUMLOOKUP(+13015611020,sip,c,loligo.com))
возвращает: $foo=3

Пример 4: Какой из указателей типа "tel", является вторым в списке? (При сортировке по приоритетам)
exten => 100,1,Set(foo=$ENUMLOOKUP(+13015611020,tel,2,loligo.com))
возвращает: $foo="+14155551212"

Пример 5: Сколько NAPTR (tel, sip, mailto и т.д.) для этого номера находятся в списке?
exten => 100,1,Set(foo=$ENUMLOOKUP(+13015611020,ALL,c,loligo.com))
возвращает: $foo=6

Пример 6: Вернуть обратно второй полный URI в отсортированом списке всех URL NAPTR:
exten => 100,1,Set(foo=$ENUMLOOKUP(+13015611020,ALL,2,loligo.com))
возвращает: $foo="tel:+14155551212" [примечание: префикс "tel:"в строке]

Пример 7: Просмотр первой записи SIP для заданого номера в зоне e164.arpa (все значения по умолчанию)
exten => 100,1,Set(foo=$ENUMLOOKUP(+437203001721))
возвращает: $foo="enum-test@sip.nemox.net" [примечание: этот результат может оказаться другим, так как это "живой" DNS и нами не контролируется]

Пример 8: Показать отбор ISN в зоне альфа-тестирования freenum.org
exten => 100,1,Set(foo=$ENUMLOOKUP(1234*256,,,freenum.org))
возвращает: $foo="1234@204.91.156.10" [Примечание: результат этого может быть другой, так как это "живое" DNS]

Пример 9: Возврат первый указателя на SIP для номера в зоне enum.yoydynelabs.com (гичего не найдено)
Exten =>100,1,Set(foo=$ENUMLOOKUP(1234567890,sip,1,enum.yoyodynelabs.com))
возвращает: $foo=""

Замечания по использованию и уточнение свойств:

а) использование "+" в поиск это заблуждение, и требует дополнительных разъяснений. Все E.164 номера ( "глобальные номера телефонов"), по определению в время поиска ENUM имеют ведущий "+". Если игнорировать наличие ведущего "+", вы можете обнаружить, что номера, которые существовуют в DNS не получают подтверждения системы или возвращают результата с нулевой строкой. Это связано с тем, что NAPTR ответ требует "+" в регулярное выражение, соответствующей последовательности. Старые версии Asterisk добавляли "+" в рамках кода, что может запутать администраторов при переходе к новой версии функции. Убедитесь до поиска, что все ENUM (e164.arpa), направляемые на поиск, содержат ведущие "+", поэтому для обеспечения поиска необходимо включать ведущий знак плюс. Другие DNS деревья может как требовать, так и не требовать ведущий "+", необходимо перед использованием этих деревьев проверить, как это можно проанализировать NAPTR на предмет исправления предоставляемых результатов, если у вас правильный строка набора номера. Если вы получаете на консоль сообщений типа "WARNING[24907]: enum.c:222 parse_naptr: NAPTR Regex match failed.", то очень возможно, что возвращаемая NAPTR ожидает ведущую "+" в строке поиска (или в вернувшемся NAPTR это неправильно сформировалось.)

b) Если запрос выполняется типа "с" ( "рассчитывать"), и допустим, что вы получите 5 записей, а затем на несколько секунд позже запроса - в адрес записи 5 в списке, возможно, и не исключено, что в от DNS резолвера получаете тот же адрес как вторую или на два меньше - может быть, есть только 4 записей в списке в нового запроса. В резольвере следует каноническим местом для хранения DNS записей, поскольку это сущность ENUM. Однако некоторые непредвиденные случии может изменить NAPTR записи в течении нескольких секунд.

Этот случае, вероятно, только стоит отметить, как случающийся в очень редких обстоятельствах. (Примечание: я не возражаю в использовании для Asterisk dnsmgr метода локального кэширования DNS ответов, но для этого метода необходимо соблюдать TTL-время удаленных первичных зон. В настоящее время в ENUMLOOKUP функции не использует dnsmgr метод локального кэширования DNS ответов)

c) Если вы получить хотите для NAPTR значения в строгом порядке, то необходимо будет использовать "ALL" метод с возвратом различных точек NAPTR по инкрементным шагам. Вам необходимо использовать манипуляции со строками для удаления типа метода, поскольку в результате возвращаемые значения будут выглядеть так: "sip: 12125551212".

Это является нетривиальной задачей, хотя это необходимо в целях обеспечения строгого соблюдения RFC и выполнять пожелания другой стороны, которая представляет NAPTR в определенном порядке по каким-то своим веским причинам.

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

Очень часто ENUM-поиск будут завершаться отказом, и это уже ответственность администратора за план набора (dialplan) по устарнения отказов за счет настроек в их планах набора (dialplan). Это переход от старого app_enumlookup метод, и это перехъоды приоритетов в зависимости от удачных или неудачных результатов.

e) В строке поиска будут игнорироваться все, кроме цифр.

Пример: строка поиска "+4372030 blah01721" превратится для поиска в "1.2.7.1.0.0.3.0.2.7.3.4.e164.arpa". Eсли внутри вашей строки NAPTR-поиска есть подстроки, синтаксический аналоиз NAPTR может дать неожиданные результаты.

f) Если в результате запроса есть несколько записей с таким же весом и порядком, функция будет случайным образом выбирать один из этих равных NAPTR -результатов.

g) В настоящее время функция игнорирует настройки в enum.conf в поисках, так как зоны теперь задаются непосредственно в функции, и пользователем через dialplan может быть выбран драйвер H323. В этом файле иные занчения не имеют значения, и поэтому он объявляется безсмысленным.

h) Функция будет усвоина и возвратит NAPTR которые используют более старый (описаный) стиль, метод реверсирования строки, так "sip + E2U" заменяет более современную "E2U + sip"

i) В настоящее время не предусматривается использование многофункциональных (multi-part) методов. Если имеется несколько NAPTR (в качестве примера) с методом "E2U + voice: sip", и еще NAPTR в той же DNS записи есть методо "" E2U + sip ", система будет рассматривать это как метод "sip", и он с точки зрения функции будут учетываться отдельно. Конечно, если обе записи к одному и тому же URI имеют (как это часто бывает) равный приоритет или вес, то это не вызовет никаких серьезных трудностей, но это должно быть упомянуть.

j) Использования ISN (Абонентский номер ITAD): Если ищется номер в формате ABC*DEF (где АВС и DEF, по крайней мере, имеют не менее одного цифрового символа), а затем исполнить поиска в стиле ISN, поиск проводится для C.B.A. DEF.domain.tld (используются все остальные настройки и параметры). Для более подробную информацию по ISN поиск см. http://www.freenum.org/. В уникальном случае необходимо избегать перезаписи ISN, в первом знаке строки поиска подставляют "n" - при поиске "n" будет игнорироваться.

Примеры

Все примеры ниже, за исключением случаев, когда указано использование "e164.arpa", как ссылающегося домена, которое является для ENUMLOOKUP именем домена по умолчанию.

Для всех номеров принято, что они не иметь лидирующего "+" при набираемом для входящего канала, так, чтобы знак, где необходимо, добавляется при обращении к функции ENUMLOOKUP.

;
; Пример 1
;
; Принимается международный префикса набор для США (011).
;
; Найти первой SIP результат и осуществить туда вызов,
; иначе передать вызов на PRI.  Это наиболее простые пример
; возможности ENUM, но использует только SIP первый ответ в
; списке NAPTR (ов).
;
exten => _011.,1,Set(enumresult=$ENUMLOOKUP(+$EXTEN:3)) 
exten => _011.,n,Dial(SIP/$enumresult) 
exten => _011.,n,Dial(Zap/g1/$EXTEN)
;
; Конец примера 1
;

;
; Пример 2
;
; Принимается международный префикса набор для США (011).
;
; Проверяется что существует  несколько SIP-результатов
; поиска NAPTR, и каждый набор в порядке. Если не работает
; (или нет существует), то вызов направляется на PRI,
; группа 1
;
exten => 
   _011.,1,Set(sipcount=$ENUMLOOKUP($EXTEN:3,sip,c)|counter=0) 
exten => _011.,n,While($["$counter" _011.,n,Set(counter=$[$counter+1]) 
exten => _011.,n,Dial(SIP/$ENUMLOOKUP(+$EXTEN:3,sip,$counter)) 
exten => _011.,n,EndWhile exten => _011.,n,Dial(Zap/g1/$EXTEN) 
;
; Конец примера 2
;

; Пример 3;
; Этот пример ожидает $EXTEN, который является номером
; e.164 (например, 14102241145 или 4137203001721). Поиск в
; e164.arpa, затем также поиск в e164.org дает увидеть,
; пока нет достоверных SIP или IAX для возможности 
; завершения, если нет ни одного, вызовов идет через 
; канал 1 Zap
;
;
; Сначала начинается с зоны e164. arpa
;
exten => 
  _X.,1,Set(sipcount=$ENUMLOOKUP(+$EXTEN,sip,c)|counter=0) 
exten => _X.,2,GotoIf($["$counter" _X.,3,Set(counter=$[$counter+1]) 
exten => _X.,4,Dial(SIP/$ENUMLOOKUP(+$EXTEN,sip,$counter)) 
exten => _X.,5,GotoIf($["$counter"  
 _X.,6,Set(iaxcount=$ENUMLOOKUP(+$EXTEN,iax2,c)|counter=0) 
exten => _X.,7,GotoIf($["$counter" _X.,8,Set(counter=$[$counter+1]) 
exten => _X.,9,Dial(IAX2/$ENUMLOOKUP(+$EXTEN,iax2,$counter)) 
exten => _X.,10,GotoIf($["$counter" _X.,11,NoOp("No valid entries in e164.arpa for 
                            $EXTEN - checking in e164.org") 
;
; Нет корректных записей в e164.arpa для 
; $EXTEN - проверка в e164.org 
;
; ... затем также проверяется e164.org и ищутся  SIP и 
; IAX NAPTRs
;
exten => 
         _X.,12,Set(sipcount=
         $ENUMLOOKUP(+$EXTEN,sip,c,e164.org)|counter=0) 
exten => _X.,13,GotoIf($["$counter" _X.,14,Set(counter=$[$counter+1]) 
exten => 
                 _X.,15,Dial(SIP/$ENUMLOOKUP(
                 +$EXTEN,sip,$counter,e164.org)) 
exten => _X.,16,GotoIf($["$counter" 
                 _X.,17,Set(iaxcount=$ENUMLOOKUP(
                 +$EXTEN,iax2,c,e164.org)|counter=0) 
exten => _X.,18,GotoIf($["$counter" _X.,19,Set(counter=$[$counter+1]) 
exten => 
                 _X.,20,Dial(IAX2/$ENUMLOOKUP(
                 +$EXTEN,iax2,$counter,e164.org)) 
exten => _X.,21,GotoIf($["$counter" _X.,22,NoOp("No valid entries in e164.org 
                for $EXTEN - sending out via Zap") 
exten => _X.,23,Dial(Zap/g1/$EXTEN) ;
;
; нет корректных входы в e164. org для 
; $EXTEN - вызов через Zap 
;
; Конец примера 3
;

Перевод можно обсудить на форуме по данной ссылке

(Мы не несем ответственность за изменениях на чужих сайтах, куда даны ссылки)