По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
При настройке телефонной маршрутизации очень часто возникает необходимость изменения (корректировки) телефонных номеров, как набираемого (Б-номер), так и инициатора вызова (А-номер, АОН). Например, абоненты вашей станции набирают междугородние/федеральные номера через префикс "8", а вышестоящему оператору связи необходимо передавать номер без префикса, в десятизначном формате. Или вызовы на вашу станцию приходят с кодом зоны, а внутри станции используются номера в 6 или 7 знаков, и лишние символы необходимо удалить. Для корректировки номеров в SoftX3000 существует множество инструментов, применяемые в зависимости от конкретных случаев. Рассмотрим некоторые из них. Таблица корректировки символов DNC Для любых операций с изменением номера используются правила таблицы DNC. Эти правила используются для непосредственной корректировки символов, а все прочие команды определяют, в отношении какого поля (А-номер или Б-номер), на каком направлении (входящее/исходящее) и на какой транк-группе будет применено это правило. Для добавления правила в эту таблицу используется команда ADD DNC. Назначение атрибутов и применение этой команды: Number change index порядковый номер правила. Используется для идентификации правила Number change type тип преобразования номера, принимает значения: NONE номер не изменяется. Используется, если нужно изменить только тип номера MOD изменение цифр номера DEL удаление цифр из номера, указываем позицию, начиная с которой удаляются цифры (Change location) и количество цифр (Change length) INS добавление цифр в номер, указываем позицию, куда вставляем цифры (Change location) и сами цифры (New number) RPL замена цифр в номере, указываем позицию, с которой начинаются цифры для замены (Change location) и сами цифры (New number) Change location позиция цифр, которые подлежат корректировке. Nature of address indicator тип номера, принимает значения: NONE тип номера не изменяется IDN международный номер NDN национальный номер UDN местный номер UNN неизвестный номер SDN специальный номер New number добавляемые (изменяемые) цифры. Для наглядности приведем реальные примеры таких правил: В таблице выше: Правило №2 изменяет первый символ в номере (Change location 0) на цифру 8 (New number). Правило №4 удаляет первые (Change location 0) два символа (Change length - 2) в номере и преобразует тип номера в международный. Правило №9 заменяет первые (Change location 0) шесть символов (Change length - 6) на номер 29xxxx. В системе можно создать 65535 правил, правило под №0 системное, изменению не подлежит. Изменение А и Б номеров на исходящем направлении Для корректировки номеров вызовах в исходящих направлениях используется две таблицы: TGLD здесь компонуются правила для А и Б номера. TGLDIDX указывает транк, в отношении которого применяется правило TGLD и условия, при которых оно применяется. При добавлении записи командой ADD TGLD, необходимо задать следующие обязательные параметры: Bearer index номер правила по порядку. Этот номер будет использоваться для идентификации в таблице TGLDIDX. Trunk seizure point минимальная длина набираемого номера. Caller sending change index правило из таблицы DNC, которое будет применено к А-номеру. Callee sending change index правило из таблицы DNC, применяемое к Б-номеру. Примеры записей TGLD: Здесь запись TGLD=1 изменяет А-номер по правилу DNC=3 и Б-номер по правилу DNC=12. Далее, необходимо привязать созданное правила TGLD к транкам. Для этого используем команду ADD TGLDIDX: Указываем следующие параметры: Trunk group number номер транка, к которому применяется данное правило. Call source code callsource источника вызова, по которому срабатывает правило. Если код отличается, правило не применится. Чтобы применить правило ко всем callsrc, необходимо указать 65534. Local DN set код Local DN set, к которому принадлежат номера/транки, совершающие вызов. Call prefix префикс, при наборе которого срабатывает правило. Bearer index номер правила из таблицы TGLD, которое было создано предыдущей командой. Пример: Рассмотрим правила, применяемые к транку №7 (столбец Trunk group number): Для вызовов с callsource=5 при наборе "8" будет применено правило TGLD=2. Для вызовов с любых прочих callsource при наборе 8 будет применено правило TGLD=17. Для вызовов с любых callsource при наборе 810 будет применено правило TGLD=1. Изменение А и Б номеров на входящем направлении Для изменения атрибутов вызова во входящем направлении применительно ко всем входящим вызовам с определенным callsrc (это может быть группа транков или группа абонентов, объединённых этим параметром), используется таблица PFXPRO. Рассмотрим назначение параметров команды ADD PFXPRO сразу на примере: Параметры имеют следующее назначение: Call source code = 0 правило будет применяться к входящим вызовам с callsrc=0 и только к ним. Call prefix = 871229 правило применяется, если Б-номер начинается с этого префикса (871229). Local DN set = 0 набор номера должен производится с транка или абонента, привязанного к Local DN set = 0. Следует отметить, что вышеуказанный префикс (871229) должен присутствовать в таблице CNACLD с любым атрибутом в указанном Local DN set. Called number change flag = true означает, что Б-номер подлежит изменению. Called number change index = 1 Б-номер будет изменен по правилу DNC=1, которое, для наглядности, приведено ниже: Согласно данному правилу, из номера Б будут удалены первые 4 символа. Reanalysis = true после всех изменений вызов снова будет обработан как вновь поступивший и смаршрутизирован согласно новым параметрам А и Б номеров. Таким образом, вызов, поступивший с атрибутом callsrc=0, в котором Б-номер соответствует шаблону 871229хххх, вновь поступит на обработку, но уже с Б-номером 29хххх, то есть будет вызван 6-значный номер внутреннего абонента станции. Таблица PFXPRO так же позволяет корректировать и А-номер (поля Caller number change flag и Caller number change index), назначить новое значение источника вызова (New call source code) и изменять некоторые другие поля. В нашей станции данная таблица используется в нескольких целях: Приведение Б-номеров по входящему направлению к виду, который мы можем маршрутизировать, то есть: от операторов связи приходит вызов на номер 871229xxxx, а номера абонентов нашей станции 29xxxx, соответственно, нам нужно отрезать первые 4 символа, чтобы распознать нашего абонента. Номера некоторых экстренных служб имеют общий вид (6-значный городской номер), однако абонент набирает короткий номер службы (01, 02, 03). Нам нужно распознать такой набор и подменить номер на реальный. Кроме того, в зависимости от того, в какой местности расположен абонент, номера одной и той же службы могут быть разными. Для того, чтобы учесть этот аспект, мы и используем атрибут callsrc (назначаем каждому району свой callsrc и в соответствии с ним осуществляем подмену набранного номера). Изменение атрибутов вызова на входящем направлении на определенном транке Для корректировки атрибутов вызова на входящем транке используется таблица CLRDSN. Запись CLRDSN привязывается к определенному транку командой ADD TGDSG. В самой команде CLRDSN можно создать несколько правил корректировки, которые будут срабатывать в зависимости от А-номера: Для добавления правила даем команду ADD CLRDSN: Здесь заполняем следующие поля: Discrimination group number номер правила, по этому номеру выполняется привязка к транку в команде ADD TGDSG (в предыдущем примере, например, мы рассматривали параметры правила №5). Caller number номер вызывающего, то есть А-номер. Можем указать конкретный номер или начальный префикс (например, если указать 995, правило будет действовать на все вызовы, которые совершаются с номеров, начинающихся на 995). Есть возможность использовать так называемый символ "Wildcard", то есть применить к любым возможным номерам, для этого вводим символ "E". Префикс в данном поле должен быть таким же, как он приходит из транка. Например, если установить префикс 906, а из транка номер буден приходить 8906 или 7906 правило не сработает. Address nature тип А-номера. Позволяет ограничить применение правила только к А-номерам определенного типа, то есть, только для Unknown неизвестный International международный National междугородный Subscriber местный All все типы номеров Function code тип действия с вызовом. Выбираем ATT(Modify caller attribute), то есть изменение атрибутов А-номера. Call source code если установить значение, код callsource будет изменен. Если оставит пустым, будет установлен callsource = 0. (Однажды потратил полдня, пока не обнаружил эту особенность). Number change index правило DNC, которое будет применено к А-номеру. Если дать команду с тем же номером Discrimination group number, но другими параметрами, правило будет добавлено в ту же группу. Таким образом, мы добавим правила для разных номеров (или разных типов номеров) в одну группу и сможем привязать ее к транку. Как было сказано ранее, привязку правила CLRDSN к транку выполняется командой ADD TGDSG. Мы используем данную функцию для нескольких сценариев. Сценарий 1 Подмена номера от подключенной УПАТС. Например, имеем некоторую УПАТС, которая подключена к нашей станции. Мы выдали им номер из нашей емкости, которую они, в том числе, должны использовать в качестве А-номера (29хххх). Однако, по какой-то причине, в поле А-номера абонент присылает нам внутренние номера своей станции (101, 102 и т.д.). а) Добавим правило DNC, которое выполнит полную подмену номера на тот, который должен быть: б) Создадим правило, в котором применим правило DNC=15 (number change index = 15), ко всем входящим вызовам (number = E, Adress nature = All number): в) Привяжем правило CLRDSN=30 к транку №30 командой ADD TGDSG: Сценарий 2 Блокировка нежелательных вызовов с транка (например, для спам-звонков). Для блокировки вызовов в станции создан Local DNset с пустой таблицей маршрутизации (в таблице CNACLD нет никаких записей), и создан callsource (callsrc=4), привязанный к этому Local DNset. При совпадении А-номера с нежелательным, вызову назначается callsrc=4, тем самым вызов не сможет быть смаршрутизирован и будет отбит. Сценарий 3 Фильтрация входящих вызовов с транка. В данном случае, изначально присваиваем траку callsrc=4, тем самым, по-умолчанию, все входящие вызовы будут запрещены. Затем создаются правила CLRDSN с определенными условиями, при соблюдении которых входящий вызов может быть смаршрутизирован. При выполнении этих условий код callsrc заменяется на разрешенный и вызов проходит. Условиями для проверки обычно выступают префикс А-номера. Например, при входящих вызовах от сотового оператора все А-номера должны начинаться на с символа "9". При входящих вызовах с наших УПАТС А-номер должен начинаться с цифр "29" и т.д. Изменение атрибутов вызова по Б-номеру для внутренних абонентов Данная функция может использоваться для разных задач. Одна из них ограничение исходящих вызовов для определенного абонента на определенный номер. В нашем примере это будут исходящие вызовы на префикс 810, то есть международные вызовы (эту задачу можно решить и другими способами). Используем команду ADD CNACLR: Здесь выделим следующие параметры: Call source code код callsrc, к которому принадлежит номер. Call prefix префикс, при наборе которого срабатывает правило. Caller number номер телефона абонента, к которому применяется правило. Здесь так же применимо выражение wildcard, то есть применить правило к любому номеру, установив символ "E". Function code тип обработки вызова. В данном случае используем изменение Б-номера, выбрав Modify caller attribute. Caller number change index правило DNC, которое применяется к А-номеру. Called number change index правило DNC, которое применяется к Б-номеру. Reanalysis flag = true устанавливаем данный флаг для повторной обработки вызова в таблице маршрутизации с новыми параметрами. Приведенное правило используется в следующем сценарии. В организации приобретен номер 8-800, вызовы на которые переадресуются на локальный номер станции 29хххх. При помощи данного правила мы можем обнаружить набор этого номера 8800 локальными абонентами и подменить его на локальный номер назначения внутри станции, тем самым избежав тарификации этих вызовов на платформе 8800, а так же снизив внешний трафик. Применение данных функций и команд не ограничивается приведенными сценариями, и ограничено только фантазией и лицензиями оборудования. Версия станции Huawei SoftX3000 V300R600, но команды будут применимы на более свежих версиях, а принцип их применения такой же.
img
Перед начало убедитесь, что ознакомились с материалом про построение деревьев в сетях. Правило кратчайшего пути, является скорее отрицательным, чем положительным экспериментом; его всегда можно использовать для поиска пути без петель среди набора доступных путей, но не для определения того, какие другие пути в наборе также могут оказаться свободными от петель. Рисунок 4 показывает это. На рисунке 4 легко заметить, что кратчайший путь от A до пункта назначения проходит по пути [A, B, F]. Также легко заметить, что пути [A, C, F] и [A, D, E, F] являются альтернативными путями к одному и тому же месту назначения. Но свободны ли эти пути от петель? Ответ зависит от значения слова "без петель": обычно путь без петель - это такой путь, при котором трафик не будет проходить через какой-либо узел (не будет посещать какой-либо узел в топологии более одного раза). Хотя это определение в целом хорошее, его можно сузить в случае одного узла с несколькими следующими переходами, через которые он может отправлять трафик в достижимый пункт назначения. В частности, определение можно сузить до: Путь является свободным от петель, если устройство следующего прыжка не пересылает трафик к определенному месту назначения обратно ко мне (отправляющему узлу). В этом случае путь через C, с точки зрения A, можно назвать свободным от петель, если C не пересылает трафик к месту назначения через A. Другими словами, если A передает пакет C для пункта назначения, C не будет пересылать пакет обратно к A, а скорее пересылает пакет ближе к пункту назначения. Это определение несколько упрощает задачу поиска альтернативных путей без петель. Вместо того, чтобы рассматривать весь путь к месту назначения, A нужно только учитывать, будет ли какой-либо конкретный сосед пересылать трафик обратно самому A при пересылке трафика к месту назначения. Рассмотрим, например, путь [A, C, F]. Если A отправляет пакет C для пункта назначения за пределами F, переправит ли C этот пакет обратно в A? Доступные пути для C: [C, A, B, F], общей стоимостью 5 [C, A, D, E], общей стоимостью 6 [C, F], общей стоимостью 2 Учитывая, что C собирается выбрать кратчайший путь к месту назначения, он выберет [C, F] и, следовательно, не будет пересылать трафик обратно в A. Превращая это в вопрос: почему C не будет перенаправлять трафик обратно в A? Потому что у него есть путь, стоимость которого ниже, чем у любого пути через A до места назначения. Это можно обобщить и назвать downstream neighbor: Любой сосед с путем, который короче локального пути к месту назначения, не будет возвращать трафик обратно ко мне (отправляющему узлу). Или, скорее, учитывая, что локальная стоимость представлена как LC, а стоимость соседа представлена как NC, тогда: Если NC LC, то тогда neighbor is downstream. Теперь рассмотрим второй альтернативный путь, показанный на рисунке 4: [A, D, E, F]. Еще раз, если A отправляет трафик к пункту назначения к D, будет ли D зацикливать трафик обратно к A? Имеющиеся у D пути: [D, A, C, F], общей стоимостью 5 [D, A, B, F], общей стоимостью 4 [D, E, F], общей стоимостью 3 Предполагая, что D будет использовать кратчайший доступный путь, D будет пересылать любой такой трафик через E, а не обратно через A. Это можно обобщить и назвать альтернативой без петель (Loop-Free Alternate -LFA): Любой сосед, у которого путь короче, чем локальный путь к месту назначения, плюс стоимость доступа соседа ко мне (локальный узел), не будет возвращать трафик обратно ко мне (локальному узлу). Или, скорее, учитывая, что локальная стоимость обозначена как LC, стоимость соседа обозначена как NC, а стоимость обратно для локального узла (с точки зрения соседа) - BC: Если NC + BC LC, то сосед - это LFA. Есть две другие модели, которые часто используются для объяснения Loop-Free Alternate: модель водопада и пространство P/Q. Полезно посмотреть на эти модели чуть подробнее. Модель водопада (Waterfall (or Continental Divide) Model). Один из способов предотвратить образование петель в маршрутах, рассчитываемых плоскостью управления, - просто не объявлять маршруты соседям, которые пересылали бы трафик обратно мне (отправляющему узлу). Это называется разделенным горизонтом (split horizon). Это приводит к концепции трафика, проходящего через сеть, действующую как вода водопада или вдоль русла ручья, выбирая путь наименьшего сопротивления к месту назначения, как показано на рисунке 5. На рисунке 5, если трафик входит в сеть в точке C (в источнике 2) и направляется за пределы E, он будет течь по правой стороне кольца. Однако, если трафик входит в сеть в точке A и предназначен для выхода за пределы E, он будет проходить по левой стороне кольца. Чтобы предотвратить зацикливание трафика, выходящего за пределы E, в этом кольце, одна простая вещь, которую может сделать плоскость управления, - это либо не позволить A объявлять пункт назначения в C, либо не позволить C объявлять пункт назначения в A. Предотвращение одного из этих двух маршрутизаторов от объявления к другому называется разделенным горизонтом (split horizon), потому что это останавливает маршрут от распространения через горизонт, или, скорее, за пределами точки, где любое конкретное устройство знает, что трафик, передаваемый по определенному каналу, будет зациклен. Split horizon реализуется только за счет того, что устройству разрешается объявлять о доступности через интерфейсы, которые оно не использует для достижения указанного пункта назначения. В этом случае: D использует E для достижения пункта назначения, поэтому он не будет объявлять о доступности в направлении E C использует D для достижения пункта назначения, поэтому он не будет объявлять о доступности D B использует E для достижения пункта назначения, поэтому он не будет объявлять о доступности в направлении E A использует B для достижения пункта назначения, поэтому он не будет объявлять о доступности B Следовательно, A блокирует B от знания альтернативного пути, который он имеет к месту назначения через C, а C блокирует D от знания об альтернативном пути, который он имеет к месту назначения через A. Альтернативный путь без петель пересекает этот разделенный горизонт. точка в сети. На рис. 12-5 A может вычислить, что стоимость пути C меньше стоимости пути A, поэтому любой трафик A, направляемый в C к месту назначения, будет перенаправлен по какому-то другому пути, чем тот, о котором знает A. C, в терминах LFA, является нижестоящим соседом A. Следовательно, A блокирует B от знания об альтернативном пути, который он имеет к месту назначения через C, и C блокирует D от знания об альтернативном пути, который он имеет к месту назначения через A. Альтернативный путь без петли будет пересекать эту точку split horizon в сети. На рисунке 5 A может вычислить, что стоимость пути C меньше стоимости пути A, поэтому любой трафик A, направленный в C к месту назначения, будет перенаправлен по какому-то другому пути, чем тот, о котором знает A. В терминах LFA, С является нижестоящим соседом (downstream neighbor) A. P/Q пространство Еще одна модель, описывающая, как работают LFA, - это пространство P / Q. Рисунок 6 иллюстрирует эту модель. Проще всего начать с определения двух пространств. Предполагая, что линия связи [E, D] должна быть защищена от сбоя: Рассчитайте Shortest Path Tree из E (E использует стоимость путей к себе, а не стоимость от себя, при вычислении этого дерева, потому что трафик течет к D по этому пути). Удалите линию связи [E,D] вместе с любыми узлами, доступными только при прохождении через эту линию. Остальные узлы, которых может достичь E, - это пространство Q. Рассчитайте Shortest Path Tree из D. Удалите канал [E, D] вместе со всеми узлами, доступными только при прохождении по линии. Остальные узлы, которых может достичь D, находятся в пространстве P. Если D может найти маршрутизатор в пространстве Q, на который будет перенаправляться трафик в случае отказа канала [E, D]- это LFA. Удаленные (remote) Loop-Free Alternates Что делать, если нет LFA? Иногда можно найти удаленную альтернативу без петель (remote Loop-Free Alternate - rLFA), которая также может передавать трафик к месту назначения. RLFA не подключен напрямую к вычисляющему маршрутизатору, а скорее находится на расстоянии одного или нескольких переходов. Это означает, что трафик должен передаваться через маршрутизаторы между вычисляющим маршрутизатором и remote next hop. Обычно это достигается путем туннелирования трафика. Эти модели могут объяснить rLFA, не обращая внимания на математику, необходимую для их расчета. Понимание того, где кольцо "разделится" на P и Q, или на две половины, разделенные split horizon, поможет вам быстро понять, где rLFA можно использовать для обхода сбоя, даже если LFA отсутствует. Возвращаясь к рисунку 6, например, если канал [E, D] выходит из строя, D должен просто ждать, пока сеть сойдется, чтобы начать пересылку трафика к месту назначения. Лучший путь от E был удален из дерева D из-за сбоя, и E не имеет LFA, на который он мог бы пересылать трафик. Вернитесь к определению loop-free path, с которого начался этот раздел-это любой сосед, к которому устройство может перенаправлять трафик без возврата трафика. Нет никакой особой причины, по которой сосед, которому устройство отправляет пакеты в случае сбоя локальной линии связи, должен быть локально подключен. В разделе "виртуализация сети" описывается возможность создания туннеля или топологии наложения, которая может передавать трафик между любыми двумя узлами сети. Учитывая возможность туннелирования трафика через C, поэтому C пересылает трафик не на основе фактического пункта назначения, а на основе заголовка туннеля, D может пересылать трафик непосредственно на A, минуя петлю. Когда канал [E, D] не работает, D может сделать следующее: Вычислите ближайшую точку в сети, где трафик может быть туннелирован и не вернется к самому C. Сформируйте туннель к этому маршрутизатору. Инкапсулируйте трафик в заголовок туннеля. Перенаправьте трафик. Примечание. В реальных реализациях туннель rLFA будет рассчитываться заранее, а не рассчитываться во время сбоя. Эти туннели rLFA не обязательно должны быть видимы для обычного процесса пересылки. Эта информация предоставлена для ясности того, как работает этот процесс, а не сосредоточен на том, как он обычно осуществляется. D будет перенаправлять трафик в пункт назначения туннеля, а не в исходный пункт назначения - это обходит запись локальной таблицы переадресации C для исходного пункта назначения, что возвращает трафик обратно в C. Расчет таких точек пересечения будет обсуждаться в чуть позже в статьях, посвященных первому алгоритму кратчайшего пути Дейкстры.
img
Введение Однажды в организации, где я работаю, случился Asterisk Случился не без моего участия, а если быть точным, то я и был главным виновником, и как следствие - главным исполнителем. Напасть была локальной, но достаточно быстро получила широкое распространение, хотя, в отдельных уголках приходилось нести прогресс в массы с применением тяжелой артиллерии и напалма. В итоге Asterisk`ом было охвачено порядка полутора тысяч абонентов. Процесс настройки абонента изначально выглядел следующим образом: Включил телефон, обновил прошивку. Пока он перезагружается, завел абонента на Asterisk (создал запись для регистрации SIP-клиента). Далее, самый очевидный способ настройки телефона - web-интерфейс; набрал в адресной строке браузера IP-адрес телефона, авторизовался, настроил два десятка параметров и готово. На всё ушло 2-3 минуты. Следующий абонент - повторяем. На втором десятке абонентов начало надоедать, появилось желание как-нибудь упростить процесс. Заглянул в настройки: экспорт и импорт конфигурации присутствует; сохранил конфигурацию телефона в файл, заглянул в него - обычный текстовый файл, в котором перечислены параметры с их значениями. Нашел параметры, значения которых менял в web-интерфейсе, причем большинство из этих параметров, хоть и отличается от дефолтных, но одинаково для всех настраиваемых в рамках данной организации телефонов. Таким образом, имея эталонный файл конфигурации и редактируя в нем всего 5-6 строк, я получал конфигурации для остальных телефонов, которые "заливал" в аппараты всё через тот же web-интерфейс. Спустя какое-то время количество абонентов заметно выросло, компания продолжала развиваться, сотрудники мигрировали между подразделениями, увольнялись, появлялись новые, некоторые телефоны выходили из строя, и возня с файлами стала постепенно отнимать много времени и раздражала с каждым днем всё больше. Тут я вспомнил про пункт меню из web-интерфейса, в котором были написаны многообещающие слова "Auto Provision". Обратимся за определением к производителям телефонов. У Dlink или Fanvil мы получим следующее: Auto Provisioning используется для реализации удаленной/автоматической инсталляции, развертывания конфигурационных и некоторых других связанных файлов. Snom дает нам практически такое же: Auto Provisioning может использоваться для предоставления общих и специфических параметров конфигурации на телефоны и для актуализации прошивки. Вроде бы всё устраивает, значит, будем для наших целей отталкиваться от этих определений. Вариантов автоматической настройки предусмотрено несколько, и без долгих терзаний, как наиболее понятный и доступный был выбран следующий: Развертывание конфигурации с tftp сервера, адрес которого телефон будет получать по DHCP в Option 66. Разберемся вкратце, что есть что. TFTP - простой протокол передачи файлов (Trivial File Transfer Protocol). В отличие от FTP основан на транспортном протоколе UDP и в нем отсутствует возможность аутентификации (однако, возможна фильтрация по IP-адресу). Одно из основных преимуществ TFTP - простота реализации клиента, поэтому он достаточно широко используется в частности для загрузки обновлений и конфигураций сетевых устройств. DHCP - протокол динамической настройки узла (Dynamic Host Configuration Protocol); сетевой протокол, позволяющий сетевым устройствам автоматически получать IP-адрес и другие параметры, необходимые для работы в сети TCP/IP. Не вдаваясь глубоко в подробности, схема обмена сообщениями DHCP при получении параметров выглядит следующим образом: DHCPDISCOVER: клиент (в нашем случае, телефон) передает это сообщение broadcast, и использует его для поиска DHCP-серверов в своей канальной среде. В одном из полей этого пакета, в поле options, клиент передает список необходимых ему опций, наиболее распространенными из которых являются: (1) - Subnet Mask (3) - Router (6) - Domain Name Server (15) - Domain Name именно в этом поле клиент сообщает о том, что ему нужен адрес tftp сервера для загрузки конфигурационного и/или других связанных файлов. Номер опции, которая его содержит - 66 (у cisco есть аналогичная опция 150, основное отличие которой в том, что она может содержать адреса нескольких tftp серверов). DHCPOFFER: cервер отвечает на запрос клиента. Сервер может передать это сообщение как broadcast так и unicast (зависит от значений полей полученных от клиента). В этом сообщении сервер предлагает клиенту параметры, которые он может отдать в текущей конфигурации. Если в сегменте сети клиента несколько DHCP серверов, то получив запрос, они все отправляют OFFER-ы. После того, как клиент выбрал, OFFER какого из DHCP серверов принять, он отправляет следующий пакет: DHCPREQUEST: казалось бы, если клиент определился, какой DHCP сервер "пришелся ему по душе", можно передать unicast-запрос этому серверу; однако предается broadcast, чтобы уведомить остальные DHCP серверы о своём выборе (добавляется опция 54, указывающая адрес выбранного DHCP-сервера), и они могли освободить зарезервированные OFFER-ы. DHCPACK: cервер отправляет подтверждение клиенту. После этого клиент настраивает свой сетевой интерфейс, используя предоставленные параметры и опции. В различных ситуациях могут еще возникать DHCPDECLINE, DHCPNAK, DHCPRELEASE, DHCPINFORM, но их рассмотрение в рамки данной статьи не входит. Для получения исчерпывающей информации о работе DHCP можно обратиться к RFC 2131: https://tools.ietf.org/html/rfc2131 Про опции 66 и 150 можно почитать здесь: https://wiki.merionet.ru/ip-telephoniya/67/dhcp-opciya-150-i-66/ https://blog.router-switch.com/2013/03/dhcp-option-150-dhcp-option-66/ Про настройку DHCP сервера и Option 66 на Mikrotik можно почитать здесь: https://wiki.merionet.ru/seti/5/nastrojka-dhcp-servera-na-mikrotik/ Чтобы передать телефону адрес tftp сервера, с которого он может получить конфигурационный файл, на DHCP сервере в параметрах области задаем Option 66, в которой указываем hostname либо IP адрес нашего tftp сервера. Настройки по-умолчанию в большинстве телефонов подразумевают получение IP-адреса по DHCP и запрос Option 66. В итоге, телефон получает IP, получает адрес tftp сервера и пытается "стянуть" оттуда файл своей конфигурации. Согласно документации Dlink, загрузка файла конфигурации происходит следующим образом: Устанавливается соединение с сервером. Проверяется наличие файла с соответствующим именем: - в первую очередь проверяется файл с именем соответствующим аппаратной платформе; - во вторую - соответствующий MAC адресу устройства; - в третью - соответствующий ID устройства; - файл с произвольным именем проверяется либо в последнюю очередь (DHCP option, UpnP) либо в первую, если он явно указан в конфигурации телефона. Проверяется версия конфигурационного файла. Если версия выше, чем текущая на телефоне, файл конфигурации применяется. Как уже говорилось ранее, файл конфигурации представляет собой текстовый документ определенного вида: Первая строка: <<VOIP CONFIG FILE>>Version:2.0002 Для того, чтобы конфигурация была применена, версия файла должна быть выше, нежели текущая на телефоне, инкрементировать требуется последний разряд версии. По-умолчанию версия конфигурации 2.0002 Пример: Текущая версия конфигурации 2.0002 на одном телефоне и 2.0004 на еще двух. Для того чтобы конфигурация применилась только на один телефон в первой строке файла конфигурации ставим <<VOIP CONFIG FILE>>Version:2.0004 для того чтобы обновить конфигурацию на всех телефонах ставим в первой строке <<VOIP CONFIG FILE>>Version:2.0005 Разделы: <GLOBAL CONFIG MODULE - содержит данные о сетевых настройках, серверах DNS, SNTP... <LAN CONFIG MODULE> - содержит данные о настройках LAN, режимах работы LAN <TELE CONFIG MODULE> - настройки расширенных функций телефонной части (Call Feature) <DSP CONFIG MODULE> - настройка кодеков <SIP CONFIG MODULE> - настройки SIP, серверы, регистрация etc... <PPPoE CONFIG MODULE> - настройки PPPoE <MMI CONFIG MODUL>E - настройки доступа и WEB интерфейса <QOS CONFIG MODULE> - qos и vlan <DHCP CONFIG MODULE> - настройки внутреннего DHCP <NAT CONFIG MODULE> - настройки NAT и ALG <PHONE CONFIG MODULE> - настройки телефонной части, в этом же разделе настраивается remote phonebook и extension key. <SCREEN KEY CONFIG MODULE> - настройка программных клавиш (для версии F3) <AUTOUPDATE CONFIG MODULE> - настройки Autoprovision <VPN CONFIG MODULE> - настройки VPN <TR069 CONFIG MODULE> - настройки TR069 Заканчивается файл строкой <<END OF FILE>> Для обновления какой-либо опции конфигурации телефона, чтобы файл конфигурации был принят телефоном достаточно наличие следующих полей: <<VOIP CONFIG FILE>> Version:2.0002 <Название необходимого раздела> Название опции: значение <<END OF FILE>> Например, для обновления имени хоста телефона необходимо создать следующий файл конфигурации: <<VOIP CONFIG FILE>>Version:2.0003 <GLOBAL CONFIG MODULE> Host Name :ReceptionPhone <<END OF FILE>> Все остальные элементы являются необязательными. Итак, овал нарисован. Остались сущие мелочи - реализовать инструмент для создания конфигураций и дальнейшего управления ими. Займемся этим в следующей публикации.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59