система Asterisk

1. 1.4. Сценарії викликів
2. 1.4.1. Перевірка голосової пошти
3. 1.4.2. Виклик зі створенням «моста»
4. 1.5. заключні коментарі
5. Примітки

Глава 1 з книги "Архітектура додатків з відкритим вихідним кодом" , Том 1.

Оригінал:, глава з книги том 1.
Автор: Russell Bryant
Переклад: Н.Ромоданов

1.4. Сценарії викликів

У двох попередніх розділах ми розглянули важливі інтерфейси компонентів системи Asterisk, а також її потокову модель виконання. У цьому розділі для того, щоб продемонструвати, як компоненти системи Asterisk компоненти спільно обробляють телефонні виклики, будуть детально розглянуті кілька найбільш поширених сценаріїв викликів.

1.4.1. Перевірка голосової пошти

Одним з типових сценаріїв є ситуація, коли хтось дзвонить для того, щоб перевірити свою голосову пошту. Першим компонентом, які бере участь в цьому сценарії, є драйвер каналу. Драйвер буде відповідальний за обробку вхідного дзвінка, який з'явиться в потоці моніторингу в драйвері каналу. Це виклик може налаштовуватися по-різному в залежності від технології, що використовується для пересилання виклику в систему. Наступним кроком налаштування виклику є визначення, кому відправляється виклик. Це зазвичай здійснюється за номером, який набирає викликає. Однак, в деяких випадках в наявності немає ніякого конкретного номера, оскільки в технології, яка використовується для пересилання виклику, немає специфікації, пов'язаної з номером, який набирали. Прикладом цього може бути вхідний дзвінок, що надходить по аналогової телефонної лінії.

Якщо драйвер каналу визначить, що для набраного номера в конфігурації Asterisk задані розширення, певні в dialplan-е (конфігурація маршрутизації виклику), то він створить об'єкт каналу Asterisk (ast_channel) і створить канальний потік. На цей канальний потік буде покладено основний обов'язок обробки решти виклику (рис.1.5).

Рис.1.5 .: Діаграма послідовності налаштування виклику

Головний цикл канального потоку здійснює виконання dialplan-а. Він дотримується правил, визначених для набраного розширення, і виконує кроки, які в них визначені. Нижче наведено приклад розширення, записаного в синтаксисі extensions.conf. У цьому розширенні вказується, що потрібно відповісти на виклик і, якщо хто-небудь набере номер * 123, виконати додаток VoicemailMain. Це той додаток, що викликається користувачем для перевірки повідомлень, що залишилися в голосовій пошті.

exten => * 123,1, Answer () same => n, VoicemailMain ()

Коли канальний потік виконає додаток Answer, Asterisk відповість на вхідний дзвінок. Відповідь на виклик вимагає спеціальної технологічної обробки, тому в добавок до деякої загальної обробці відповіді також викликається функція зворотного виклику answer, що знаходиться в асоційованої структурі ast_channel \ tech, яка буде обробляти виклик. При цьому може відбуватися відсилання по мережі спеціального пакета поверх мережі IP, який повідомляє, що в аналогової лінії потрібно зняти трубку і т.д.

Наступним кроком для канального потоку буде виконання програми VoicemailMain (рис.1.6). Ця програма надається у вигляді модуля app_voicemail. Слід зауважити, що хоча додаток Voicemail виконує великий обсяг роботи, необхідний при взаємодії з викликами, в ньому нічого не відомо про технології, що використовується для передачі виклику в систему Asterisk. Абстракція каналу The Asterisk приховує ці особливості від реалізації скриньку голосової пошти.

Є цілий ряд можливостей, які надаються яка звернулася до своєї голосової пошти. Однак всі вони, перш за все, реалізовані як операції читання і запису звукових файлів, що виконуються у відповідь на введення команд, що надходять від абонента, які, в основному, є натисканням клавіш з цифрами. Сигнали про натискання клавіш можуть надходити в Asterisk різними способами. Але знову, з цими особливостями справляються драйвери каналів. Як тільки натискання клавіші надходить в систему Asterisk, воно конвертується в узагальнене подія про натискання клавіші і передається в код програми Voicemail.

Одним з важливих інтерфейсів в системі Asterisk, який ми вже розглядали, є транслятор кодеків. Такі реалізації кодеків важливі для даного сценарію виклику. Коли в коді голосової пошти потрібно зухвалому відтворити звуковий файл, аудіоформат в звуковому файлі може не збігтися з аудіоформаті, використовуваним при комунікації між системою Asterisk і зухвалим. Якщо буде потрібно перетворити аудіоформат, то для того, щоб з вихідного формату отримати цільовий формат, буде створено послідовність перетворень (translation path), що складається з одного або декількох трансляторів кодеків.

Рис.1.6: Виклик скриньку голосової пошти VoicemailMain

В деякий момент викликає завершить своє спілкування з системою голосової пошти і повісить трубку. Драйвер каналу виявить, що це сталося, і перетворює цю подію в узагальнене сигнальне подія каналу Asterisk. Код додатка Voicemail отримає це сигнальне подія і закінчить своє виконання. Управління буде повернуто в основний цикл в канальному потоці, в результаті чого можна буде продовжити виконання dialplan-а. Оскільки в цьому прикладі в dialplan-е немає нічого, що потрібно обробляти, драйвер каналу отримає можливість спеціальний чином, залежать від використовуваної технології, обробити крок відключення виклику, після чого об'єкт ast_channel буде знищений.

1.4.2. Виклик зі створенням «моста»

Ще одним досить загальним сценарієм викликів в системі Asterisk є виклик зі створенням «моста» між двома каналами. Це сценарій, коли один телефон через систему викликає інший телефон. Початковий етап процесу налаштування виклику аналогічний тому, який був розглянутий в попередньому прикладі. Відмінності в обробці починаються після того, як виклик був налаштований і канальний потік починає виконання dialplan-а.

Наступний dialplan є простим прикладом, результатом виконання якого буде виклик з використанням з'єднання типу «міст». Коли на телефоні буде набраний номер 1234, то при використанні даного розширення dialplan виконає додаток Dial, яке є основним додатком, використовуваним для ініціації вихідного дзвінка.

exten => 1234,1, Dial (SIP / bob)

Аргумент, що вказується в додатку Dial, повідомляє, що система повинна створити вихідний дзвінок на пристрій, що позначається як SIP / bob. Частина SIP цього аргументу вказує, що для доставки даного виклику повинен використовуватися протокол SIP. bob буде проінтерпретувати драйвером каналу, який повинен реалізовувати протокол SIP, тобто chan_sip. Якщо припустити, що в драйвері каналу був належним чином налаштований акаунт з ім'ям bob, то буде відомо, як можна буде отримати доступ до телефону Боба.

Додаток Dial запросить базову частину системи Asterisk виділити новий канал, який використовує ідентифікатор SIP / bob. Базова частина запросить драйвер каналу SIP виконати спеціальну ініціалізацію, що відповідає даній технології. Драйвер каналу також ініціює процес дозвону до телефону. Як тільки прийде відповідь на цей виклик, драйвер передасть події назад в базову частину Asterisk, які будуть прийняті додатком Dial. Ці події можуть говорити про те, що надійшла відповідь на виклик, що напрямок зайнято, що мережа перевантажена, що виклик був відхилений з деякої причини або про ряд інших подій. В ідеальному випадку буде отримана відповідь на виклик. Той факт, що на виклик була отримана відповідь, повернеться назад у вхідний канал. Asterisk не відповість на вхідний дзвінок до тих пір, поки не на вихідний виклик не надійде відповідь. Ка тільки обидва канали дадуть відповідь на виклик, між ними буде встановлено з'єднання типу «міст» (рис.1.7).

Ріс.1.7: Блок-схема мостового виклику всередині узагальненої абстракції типу «міст»

Коли через міст відбудеться з'єднання каналів, аудиопоток і сигнальні події будуть передаватися між каналами до тих пір, поки не виникне деяка подія, що призводить до розриву мостового з'єднання, наприклад, коли на одній стороні повісять трубку. На рис.1.8 наведена діаграма, що демонструє ключові операції, виконувані з аудіофреймом при використанні з'єднання типу «міст».

Рис.1.8 Діаграма послідовності дій при обробці аудіо фрейму для з'єднання типу «міст»

Після того, як виклик буде завершено, процес роз'єднання буде схожий на той, що описаний в попередньому прикладі. Головна відмінність тут в тому, що даному процесі беруть участь два канали. Перш, ніж канальний потік припинить своє існування, для обох каналів буде виконана спеціальна процедура роз'єднання, обумовлена ​​технологією, яка використовується в кожному з каналів.

1.5. заключні коментарі

Архітектурі системи Asterisk в даний час вже більше десяти років. Однак фундаментальні концепції каналів і гнучкої обробки викликів, які використовуються в dialplan-е системи Asteris, як і раніше дозволяють підтримувати розробку складних систем телефонії в галузі, яка постійно розвивається. Однією з областей, з якою архітектура системи Asterisk не може досить добре впоратися, є масштабування системи на декількох серверах. Спільнота розробки Asterisk розробляє в даний час супутній проект, який називається Asterisk SCF (Scalable Communications Framework - Масштабований комунікаційний фреймворк), призначений для вирішення цих проблем масштабованості. У найближчі кілька років ми очікуємо побачити, що система Asterisk разом з системою Asterisk SCF буде продовжувати займати все більшу частину ринку телефонії, в тому числі в області великих систем.

Примітки

1. http://www.asterisk.org/
2. DTMF є скороченням Dual-Tone Multi-Frequency (режим двотонального многочастотного набору). Це сигнал, який надсилається як телефонний аудіосінал, коли хто-небудь на своєму телефоні натискає клавішу з цифрою.

До початку статті .

Якщо вам сподобалася стаття, поділіться нею з друзями: