По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В процессе нашей работы, часто приходится сталкиваться с ситуациями, когда заказчик, при переходе от аналоговой телефонии (ТФОП – Телефонная Сеть Общего Пользования) к VoIP не может отказаться от имеющегося у него аналогового оборудования. Это могут быть как аналоговые телефоны, факсимильные и модемные устройства так и вся аналоговая АТС. Причины могут быть абсолютно разные, но решение всегда одно - поставить специальные шлюзы c FXS/FXO интерфейсами, с помощью которых можно "подружить" аналоговый мир и мир IP.
Как можно догадаться FXS/FXO интерфейсы (или порты) - это аналоговый мир и одно не может существовать без другого. Что же это за интерфейсы и как они работают - читайте в этой статье.
Предыстория
Традиционная аналоговая телефонная сеть – это совокупность технических сооружений и аналоговых линий связи, обеспечивающих возможность осуществления телефонных соединений по средствам аналоговых телефонных аппаратов. Подключение к телефонной сети общего пользования (POTS – Plain Old Telephone Service) - это услуга, которую предоставляет местная телефонная компания из своих центральных офисов (CO – Central Office) для домашних или офисных абонентов. Подключение осуществляется с помощью электрических проводов, состоящих из двух медных жил. Чтобы увеличить расстояние, на которое может быть передан сигнал и уменьшить электромагнитные помехи, жилы скручиваются вместе, такой метод называется «витая пара».
Интерфейс FXS
Медные провода протягиваются до помещений конечных абонентов (квартиры и жилые дома – для домашних абонентов, офисные здания и комнаты – для офисных абонентов) и заканчиваются в виде телефонной розетки в стене, как правило, с разъёмом стандарта RJ-11 (У кого то может быть ещё остались советские РТШК).
И это, дорогие друзья, и есть тот самый интерфейс или порт FXS – Foreign eXchange Subscriber / Station, по которому местная телефонная компания предоставляет сервис POTS. В данный порт должны подключаться оконечные абонентские устройства, такие как телефон, факс или модем. Буква ”S”- (Subscriber - абонент) в аббревиатуре FXS как бы подсказывает, что данный интерфейс будет ожидать подключения именно от абонентcкого устройства.
Основные функции, которые обеспечивает FXS порт это:
Зуммер - непрерывный сигнал, который Вы слышите, когда снимаете трубку, означающий, что телефонная станция готова принимать номер. В англоязычной литературе – Dial Tone;
ток заряда батареи питания линии
Напряжение линии - постоянное напряжение аналоговой телефонной линии, необходимое для осуществления звонка;
Итак, запомните – к FXS всегда подключаем абонентские оконечные устройства, это то, что мы получаем от провайдера телефонной связи.
Интерфейс FXO
Устройства FXO – Foreign eXchange Office - это устройства, которые получают сервис POTS, то есть это оконечные устройства – телефоны, факсы модемы и так далее. Эти устройства также имеют разъём стандарта RJ-11 и ожидают подключения со стороны телефонной станции (CO – Central Office), о чем свидетельствует буква «O» - Office в аббревиатуре FXO.
Данный интерфейс обеспечивает функции определения поднятия трубки (on-hook/off-hook), то есть факт замыкания цепи, которая в свою очередь вызывает отправку Dial Tone со стороны телефонной станции.
Итак, запомните – к FXO всегда подключаем линию от провайдера телефонной связи.
А теперь, закрепим усвоенное.
FXS порт – это наша домашняя (или офисная) телефонная розетка, которую нам предоставляет провайдер телефонных услуг. К ней мы подключаем абонентские аппараты (телефоны, факсы и прочие)
FXO порт – это разъем на нашем телефоне, его мы всегда подключаем к FXS, то есть к телефонной станции провайдера услуг POTS.
Кстати, важно отметить, что нельзя подключить FXO устройство к другому FXO устройству, ну и FXS к FXS. Например, если вы напрямую соедините два телефона (FXO), то вы не сможете позвонить с одного на другой.
Аналоговые УАТС и FXS/FXO
Если в офисе используется старая аналоговая учрежденческая АТС (УАТС), то это немного меняет картину. УАТС должна иметь оба типа интерфейсов, как FXS, так и FXO.
Линии от провайдера телефонных услуг (FXS), должны подключаться к FXO интерфейсам аналоговой УАТС, обеспечивая Dial Tone и напряжение линии, а сами оконечные устройства – телефонные аппараты, как устройства FXO, должны подключаться к FXS интерфейсам аналоговой УАТС и обеспечивать определения снятия трубки.
VoIP и FXS/FXO
Как я уже писал в начале статьи, для того, чтобы «подружить» аналоговый мир и мир IP, необходимо использовать VoIP шлюзы. Однако то, какой именно использовать шлюз FXO или FXS – зависит от ситуации. Как правило ситуаций всего две:
Пример №1
У нас есть медные линии от местной телефонной компании, но отказываться мы от них не хотим. Планируем поставить в качестве офисной телефонной станции IP-АТС Asterisk.
В этом случае нам нужен FXO шлюз. Медные линии от провайдера (FXS) мы подключаем в FXO порты шлюза, а к Ethernet портам шлюза подключается IP-АТС Asterisk. FXO шлюз производит преобразование аналоговых сигналов от аналоговой станции нашей местной телефонной компании в цифровые сигналы, которые понимает IP-АТС Asterisk. Схема такая:
Пример №2
У нас есть аналоговые телефоны и факс, отказываться от них мы не хотим. Однако отказались от старой аналоговой АТС и перешли на IP-АТС Asterisk
В этом случае, нам нужен FXS шлюз. Наши аналоговые телефоны – это аппараты FXO, поэтому их мы подключаем к FXS портам шлюза, а к Ethernet порту подключаем IP-АТС Asterisk. FXS шлюз осуществляет преобразование аналоговых сигналов от аналоговых телефонов в цифровые сигналы, которые понимает Asterisk. Схема примерно такая:
На этом всё, друзья. Искренне надеюсь, что данная статья поможет вам разобраться в разнице между FXS и FXO интерфейсами и пригодится в ваших проектах :)
Универсальный уникальный идентификатор (UUID - Universally Unique Identifier) – это форма идентификатора, которую можно с уверенностью признать уникальной для большинства практических целей. Даже если два UUID были сгенерированы в двух различных средах двумя сторонами, они имеют ничтожные шансы на то, чтобы оказаться идентичными. Именно поэтому UUID считаются универсально уникальными.
В этой статье мы с вами рассмотрим характеристики UUID, то, как работает их уникальность, и сценарии, для которых они могут упростить процесс идентификации ресурсов. Несмотря на то, что мы будем рассматривать UUID с точки зрения программного обеспечения, которое взаимодействует с записями базы данных, их также можно применять и в других ситуациях, где требуется децентрализованная генерация уникальных идентификаторов.
Что такое на самом деле универсальный уникальный идентификатор (UUID)?
UUID – это просто значение, которое с уверенностью можно рассматривать как уникальное. Вероятность обнаружения двух одинаковых UUID настолько мала, что ее можно просто игнорировать. Вы можете встретить и другие термины для UUID, например, GUID (Globally Unique Identifier, - глобальный уникальный идентификатор) (такой вариант предпочитает Microsoft), однако смысл и свойства остаются теми же.
Истинный UUID – это уникальный идентификатор, который был сгенерирован и представлен в стандартизированном формате. Допустимые UUID определены в спецификации RFC 4122. Она описывает алгоритмы, которые можно использовать для генерации UUID, которые бы сохраняли свою уникальность в различных реализациях без участия основной выдающей стороны.
В RFC есть пять различных алгоритмов. У каждого из этих алгоритмов есть свой собственный механизм генерации значений. Ниже приведено краткое описание доступных «версий»:
Версия 1 – Time-Based – объединяет метку времени, тактовую последовательность и значение, которое является характерным для генерирующего устройства (как правило, это MAC-адрес); таким образом создается выходное значение, которое является уникальным для этого хоста на определенный момент времени.
Версия 2 – DCE Security – эта версия была создана как модификация Версии 1, которую можно использовать в среде распределенных вычислений (DCE - Distributed Computing Environment). Применяется не так часто.
Версия 3 – Name-Based (MD5) – MD5 хеширует «пространство имен» и «имя» для того, чтобы создать значение, которое будет уникальным для этого имени в пределах пространства имен. Попытка создать другой UUID с тем же пространством имен и тем же именем приведет к тому, что вы получите идентичный результат. Так что, этот метод дает воспроизводимые результаты.
Версия 4 – Random – большинство современных систем выбирают именно эту версию, поскольку здесь для получения выходного значения используется источник случайных и псевдослучайных чисел. Вероятность того, что будут созданы два одинаковых UUID, ничтожна мала.
Версия 5 – Name-Based (SHA-1) – эта версия в какой-то степени похожа на Версию 3, но здесь для хеширования пространства имен и имени используется более криптостойкий алгоритм SHA-1.
Хоть в RFC алгоритмы и обозначены как «версии», это ни в коем случае не значит, что всегда нужно использовать Версию 5, потому что она вроде бы самая новая. Выбор версии зависит от вашего варианта использования; зачастую выбирается Версия 4 из-за случайного характера генерации значений. Именно это делает ее идеальным вариантом для простых сценариев из разряда «дайте мне новый идентификатор».
Алгоритмы генерации на выходе дают 128-битное целое число без знака. Но при этом UUID чаще всего рассматривают как шестнадцатеричные строки. Также их можно хранить в виде двоичной последовательности из 16 символов. Ниже приведен пример UUID:
16763be4-6022-406e-a950-fcd5018633ca
Значение записано с помощью пяти групп буквенно-числовых символов, разделенных дефисом. Последние не являются обязательными составляющими строки; их наличие связано с историческими тонкостями спецификации UUID. А еще они значительно облегчают зрительное восприятие идентификатора.
Варианты использования UUID
В основном UUID используют для децентрализованного создания уникальных идентификаторов. Вы можете создать UUID где угодно и с уверенностью сказать, то он уникальный, независимо от того, был он создан на вашем сервере, в клиентском приложении или в вашей базе данных.
UUID упрощают определение и обеспечение идентичности объекта в изолированных средах. Согласно сложившейся практике, большинство приложений в качестве первичного ключа используют целочисленное поле с автоинкрементом. В таком случае, когда вы создаете новый объект, то вы не узнаете его идентификатор до тех пор, пока не добавите его в базу данных. С помощью UUID вы можете определить идентификатор в вашем приложении намного раньше.
Ниже приведен демонстрационный пример, написанный на PHP, который покажет разницу. Для начала давайте посмотрим на целочисленную систему:
class BlogPost {
public function __construct(
public readonly ?int $Id,
public readonly string $Headline,
public readonly ?AuthorCollection $Authors=null) {}
}
#[POST("/posts")]
function createBlogPost(HttpRequest $Request) : void {
$headline = $Request -> getField("Headline");
$blogPost = new BlogPost(null, $headline);
}
Мы должны инициализировать свойство
$Id
как
null
, поскольку мы не будем знать его фактический идентификатор до тех пор, пока не добавим его в базу данных. Это не самый идеальный вариант –
$Id
не должен обнуляться, из-за этого экземпляры
BlogPost
находятся в незавершенном состоянии.
Перейдем к UUID; это решит проблему:
class BlogPost {
public function __construct(
public readonly string $Uuid,
public readonly string $Headline,
public readonly ?AuthorCollection $Authors=null) {}
}
#[POST("/posts")]
function createBlogPost(HttpRequest $Request) : void {
$headline = $Request -> getField("Headline");
$blogPost = new BlogPost("16763be4-...", $headline);
}
Идентификаторы публикаций теперь можно создавать прямо в приложении, не думая о том, что они могут повториться. Это гарантирует, что экземпляры объекта всегда находятся в действительном состоянии и что ну нужно присваивать ID нулевое значение. Также эта модель упрощает обработку транзакционной логики; дочерние записи, которым нужна ссылка на родителя (например, взаимосвязи автора (
Author
) нашей публикации), могут быть добавлены немедленно, и не нужно обращаться к базе данных для того, чтобы получить идентификатор родителя.
В перспективе большую часть логики данного приложения-блога можно будет переместить на клиентскую сторону. Возможно, внешний интерфейс сможет поддерживать полностью автономное создание черновиков, по сути создавая экземпляры
BlogPost
, которые будут временно сохраняться на устройстве пользователя. Теперь клиент может создавать UUID для публикации и, если ему нужно будет восстановить подключение к сети, передавать его на сервер. Если в обозримом будущем клиент получит копию черновика с сервера, то он сможет сравнить ее с любым сохранившимся локальным состоянием, так как он уже будет знать UUID.
С помощью UUID можно комбинировать данные из различных источников. Объединение таблиц базы данных и кэшей, которые используют целочисленные первичные ключи, может оказаться довольно трудоемким процессом, и, плюс ко всему, в процессе могут возникать ошибки. UUID обеспечивает уникальность идентификатора не только внутри таблиц, но и на уровне всего пространства. Это делает их более предпочтительным вариантом для дублируемых структур и данных, которые часто необходимо перемещать из одной системы хранения в другую.
Нюансы, возникающие при встрече UUID с базами данных
Преимущества UUID довольно привлекательны. Однако есть несколько подводных камней, о которых следует помнить при использовании UUID в реальных системах. Один из значительных факторов в пользу целочисленных идентификаторов – их легко масштабировать и оптимизировать. Механизмы управления базами данных могут с легкостью индексировать, сортировать и фильтровать список чисел, которые идут одно за другим.
А вот про UUID такого сказать нельзя. Прежде всего, UUID в четыре раза больше, чем целое число (36 против 4 байтов); для больших наборов данных этот факт уже может быть существенным моментом. Такие значения намного сложнее сортировать и индексировать, особенно если речь идет о случайных UUID, которые являются самыми популярными. Их случайный характер говорит о том, что они не имеют естественного порядка. Если вы используете UUID в качестве первичного ключа, то это может навредить производительности при индексировании.
Все эти проблемы могут усугубляться в хорошо нормализованной базе данных, которая активно использует внешние ключи. В таком случае у вас может оказаться большое количество реляционных таблиц, каждая из которых хранит ссылки на ваши 36-байтные UUID. В конечном счете, дополнительная память, которая необходима для выполнения операций объединения и сортировки, может негативно сказаться на производительность вашей системы.
У вас есть возможность немного сгладить нежелательные последствия, сохранив свои UUID в виде двоичных данных. Это значит, что вместо столбца
VARCHAR(36)
у вас будет столбец
BINARY(16)
. Некоторые базы данные, например, PostgreSQL, имеют встроенный тип данных
UUID
; другие, например, MySQL, имеют специальные функции, которые преобразовывают строку UUID в двоичную форму и наоборот. Такой подход, конечно, более эффективный, но не забывайте, что вам по-прежнему придется использовать дополнительные ресурсы для хранения и выборки данных.
Эффективной может оказаться стратегия, когда вы в качестве первичных ключей оставляете целые числа, но при этом добавляете дополнительное поле UUID для того, чтобы ваше приложение могло на него ссылаться. Реляционные таблицы ссылок могут использовать идентификаторы для повышения производительности, пока ваш код извлекает и вставляет объекты верхнего уровня с UUID. Здесь все зависит от вашей системы, ее масштаба и ваших приоритетов: если вам нужна децентрализованная генерация идентификаторов и простейшее слияние данных, то лучший вариант – это UUID, но вам следует помнить и об обратной стороне медали.
Заключение
UUID – это уникальные значения, которые можно использовать для децентрализованной генерации идентификаторов. Совпадение идентификаторов возможно, но вероятность такого события настолько мала, что ее можно не учитывать. Если бы вы генерировали один миллиард UUID в секунду в течении 100 лет, то вероятность обнаружить дубликат составила бы около 50% при условии наличия достаточной энтропии.
У вас есть возможность использовать UUID для установления идентичности независимо от вашей базы данных до того, как вы добавите объект в базу данных. Такой подход упрощает код прикладного уровня и не допускает того, что объекты в вашей системе будут идентифицированы неправильно. UUID также содействуют репликации данных, гарантируя уникальность вне зависимости от хранилища данных, устройства или среды, чего нельзя сказать о целочисленных ключах, которые действуют на уровне таблиц.
Несмотря на то, что UUID широко используются при разработке программного обеспечения, они не являются идеальным решением. Новички часто зацикливаются на возможности обнаружения совпадений, но это не должно быть вашим главным аргументом, если только ваша система не настолько чувствительна, что вам просто необходимо гарантировать уникальность идентификаторов.
Более очевидная проблема для большинства разработчиков заключается в хранении и извлечении сгенерированных UUID. Примитивное использование
VARCHAR(36)
(или
VARCHAR(32)
, если вы удалите дефисы) в долгосрочной перспективе может оказывать негативное влияние на ваше приложение, так как большая часть попыток оптимизировать индексацию базы данных будут неэффективными. Изучите встроенные средства обработки UUID в вашей системе управления базой данных для того, чтобы максимально улучшить производительность вашего программного решения.
В данной статье я опишу несложный процесс регистрации нового транка при помощи web – интерфейса FreePBX 13. Процесс продемонстрирован при выборе провайдера Celecom (www.celecom.ru) , но он достаточно схож для многих провайдеров.
Пошаговое видео
Добавить SIP - транк
Необходимо попасть в меню администрирования транков по следующему пути:
Connectivity → Trunks
Далее нажать «Add Trunk» и выбрать необходимый тип транка.
В данном случае выберем опцию Add SIP (chan_sip) Trunk
Далее необходимо придумать имя транка, в данном случае trunktest.
Коротко про опции в данном поле:
Trunk Name - Название транка
Hide CallerID - Опция скрытия CID при исходящем вызове
Outbound CallerID CID, который будет передаваться при исходящем вызове
CID Options - Настройки передачи CID – разрешить все, запретить иностранные и т.д
Maximum Channels - максимальное количество одновременных разговоров вне локальной сети
Asterisk Trunk Dial Options - модификация Dial options, в данном случае оставим опцию дефолтной
Continue if Busy - опция направления вызова на следующий транк даже если канал сообщает «BUSY» или «INVALID NUMBER»
Disable Trunk - опция выключения транка
Далее необходимо проследовать в поле «sip Settings»
Для начала настроим настройки исходящих вызовов в поле «Outgoing»
Дублируем название транка и вставляем настройки:
host=sip.sun-tel.ru
type=peer
context=from-trunk
username=ваш_sipid -логин, который выдается провайдером(ваш номер)
secret=ваш_пароль – пароль, выданный провайдером
fromuser= ваш_sipid
fromdomain=sip.sun-tel.ru
qualify=yes
insecure=invite,port
faxdetect=no
account=celecom
Заключительный шаг – необходимо ввести строку регистрации (registration string) в поле «Incoming»
ваш_Sipid:PASSWORD@sip.sun-tel.ru/ВАШ_НОМЕР
Если все было сделано правильно, то необходимо нажать Submit и Apply Config.
Если данные аккаунты верны, то в окне мониторинга «Dashboard» вы увидите, что транк поднялся.
Настройка исходящих и входящих маршрутов будет рассмотрена в следующей статье.