Исходящий звонок Asterisk — базовая настройка
Настройку будем производить в /etc/asterisk/extensions.conf и /etc/asterisk/sip.conf
Сначала посмотрим информацию по приложению которое будем использовать
Переходим в консоль сервера телефонии
Выводим все приложения
Теперь из списка выбираем dial и просматриваем информацию по нему
core show applications like dial
core show applications description dial
Информация при этом соотносится с используемой версией пакета
Правим extensions.conf настроенный ранее
[phones]
exten => 100,1,NoOp(First Line)
exten => 100,2,NoOp(Second Line)
exten => 100,3,Dial(Sip/user1)
exten = > 100,4,Hangup
После указания номера 100 идет порядковый номер правила, а затем название протокола — Sip в данном случае — и через слэш имя пользователя, который задан в sip.conf
После того как сделан вызов обязательно нужно использовать Hangup
Сейчас можно звонить на extention 100 (т.е. авторизовавшись в программном телефоне или используя аппаратный телефон звонить на 100), при звонке в консоли Asterisk видно, что вызов проходит, но после окончания звонка можно увидеть такую ошибку:
«unable to reopen master file /var/log/asterisk//cdr-csv//Master:csv» :Permistion denied
Она вызвана существованием некорреткных прав и легко исправляется
chown asterisk /var/log/asterisk//cdr-csv//Master.csv
Сейчас исходящий звонок должен проходить без ошибок.
Добавляем аналогичные строки в конфигурационный файл для второго пользователя
[phones]
exten => 100,1,NoOp(First Line)
same => n,NoOp(Second Line)
same => n,Dial(Sip/user1)
same = > n,Hangup
exten => 200,1,NoOp(First Line)
same => n,NoOp(Second Line)
same => n,Dial(Sip/user2)
same = > n,Hangup
Здесь использован более совершенный синтаксис — для каждого последующего правила прописывается same, а порядковый номер заменяется на n, что действительно для всех номеров кроме первого (который всегда указывается) — это является хорошей практикой и исключает возможность неправильного выполнения программы, например, при перестановке строк.
После перезапуска диалплана пользователи могут беспрепятственно звонить друг другу.
Проигрывание звукового файла при звонке
Добавим проигрывание определенного звукового файла при звонке на одно из расширений
exten => 100,1,NoOp(First Line)
same => n,NoOp(Second Line)
same => n,Dial(Sip/user1)
same = > n,Hangup
exten => 200,1,NoOp(First Line)
same => n,NoOp(Second Line)
same =>n,Playback(tt-monkeys)
same => n,Dial(Sip/user2)
same = > n,Hangup
Теперь при звонке на 200 сначала будет проигрываться один из стандартных звуковых фрагментов, потом будет совершаться вызов на user2.
Настроим возможность звонить во внешний мир
Строк с playback из предыдущего примера здесь нет, в остальном диалплан тот же.
exten => 100,1,NoOp(call for user1)
same => n,Dial(Sip/user1)
same = > n,Hangup
exten => 200,1,NoOp(call for user2)
same => n,Dial(Sip/user2)
same = > n,Hangup
exten => 8888,1,Goto(ougoing,8888,1)
[outgoing]
extent => 8888,1,Dial(SIP/outside)
Вводим новое расширение outgoing, а при звонках на 8888 вызовы будут перенаправляться пользователю outside из sip.conf — обычно это провайдер телефонии.
Теперь если user1 или user2 будут набирать 8888 телефон пользователя outside будет звонить.
Если мы хотим звонить не только на номер 8888 (а это обычно так, то используем регулярное выражение)
[phones]
exten => 100,1,NoOp(call for user1)
same => n,Dial(Sip/user1)
same = > n,Hangup
exten => 200,1,NoOp(call for user2)
same => n,Dial(Sip/user2)
same = > n,Hangup
exten => _XXXX,1,Goto(ougoing,8888,1)
[outgoing]
extent => 8888,1,Dial(SIP/outside)
Все регулярные выражения начинаются с нижнего подчеркивания, ХХХХ означает, что провайдеру вызов будет переадресован случае если номер состоит из 4-х цифр, для номера произвольной длины можно использовать _0X.
Если после настройки звука нет или он есть частично нужно выяснить за NAT-ом ли клиент и сервер и скорректировать конфигурацию.
Эффективное использование сервисных кодов перевода вызова в Asterisk
Многие знают о существовании в Asterisk сервисных кодов для управляемого и неуправляемого перевода вызова, далеко не все знают особенности их настройки. В этой статье будет описана настройка сервисных кодов для эффективного использования перевода вызова. Настройка параметров сервисных кодов Asterisk Настройки сервисных кодов Asterisk находятся в файле features.conf, по умолчанию, сервисные коды следующие:управляемый перевод — не […]
Многие знают о существовании в Asterisk сервисных кодов для управляемого и неуправляемого перевода вызова, далеко не все знают особенности их настройки. В этой статье будет описана настройка сервисных кодов для эффективного использования перевода вызова.
Настройка параметров сервисных кодов Asterisk
Настройки сервисных кодов Asterisk находятся в файле features.conf, по умолчанию, сервисные коды следующие:
управляемый перевод — не задан
неуправляемый перевод — #
отбой вызова — *
Как видите, управляемым переводом вообще нельзя пользоваться по умолчанию. Вносим в раздел [featuremap] файла features.conf:
Для применения изменений в файле features.conf, нужно выполнить команду в CLI Asterisk «features reload»:
Теперь имеем следующие сервисные коды:
управляемый перевод — *
неуправляемый перевод — ##
отбой вызова — **
Схожесть кодов управляемого перевода и отбоя вызова не является проблемой, т.к. в описываемой схеме эти коды никогда не будут доступны пользователю одновременно.
В разделе файла features.conf [general] указываются различные параметы сервисных кодов, обратите внимание на следующие:
featuredigittimeout — максимальная задержка между вводом символов при наборе сервисных кодов в миллисекундах. Значение по умолчанию — 1000, т.е. 1 секунда. Для ввода сервисных кодов, предлагаемых в этой статье, секунды должно хватить. Для ввода более сложных сервисных кодов пользователям может периодически не хватать времени, поэтому рекомендуется увеличить значение этого параметра до 2000.
transferdigittimeout — максимальная задержка в секундах между вводом символов при наборе номера адресата перевода. Значение по умолчанию — 3. Для более комфортного ввода номера, нужно увеличить это время до 4-5 секунд.
Atxferdropcall — при значении по умолчанию «no», если при упарвляемом переводе переводящий кладёт трубку не дожидаясь ответа адресата перевода и адресат перевода так и не принимает вызов до достижения таймаута вызова (значение параметраatxfernoanswertimeout), Asterisk попытается вернуть вызов переводящему. Asterisk может пытаться вызвать переводящего определённое количество раз (значение параметра atxfercallbackretries) с определённым интервалом (значение параметра atxferloopdelay). Если установить значение параметра atxferdropcall равным «yes», то Asterisk не будет пытаться вернуть вызов переводящему после неудачного управляемого перевода. Нужно установить значение «yes», если обработака вызова после неудачного перевода вызова реализована средствами диалплана.
ПРИМЕЧАНИЕ: Стандартный механизм возврата вызова после неудачного управляемого перевода не очень хорош, т.к. он не проверяет, свободен ли абонент, на которого должен вернуться вызов, не позволяет выполнять диалплан и не имеет возможности перевести вызов кому-либо другому, если абонент, совершивший перевод, не берёт трубку. Рекомендуется использовать вместо этого возврат вызова, реализованный средствами диалплана.
Для примеров, приведённых в этой статье, использовались следующие значения параметров в разделе [general] файла features.conf:
Написание диалплана Asterisk для обработки перевода вызовов
Предположим, что для совершения вызовов используется следующий несложный диалплан:
Пояснения к диалплану:
— вызовы пользователей 100-109 совершаются в контексте from-10X
— вызовы пользователя 110 совершаются в контексте from-110
— вызовы остальных пользователей совершаются в контексте internal-default
— входящие вызовы приходят в контекст from-trunk
— номер очереди сохраняется в переменную PREVIOUS_QUEUE перед входом в очередь — после вызова MixMonitor вызывается функция AUDIOHOOK_INHERIT, это нужно для того, чтобы запись продолжалась после перевода вызова
Для того, чтобы абоненты могли использовать сервисные коды перевода вызова, приложения, осуществляющие вызовы абонентов, должны использоваться с опциями разрешающими использование сервисных кодов для перевода вызова. В приведённом диалплане приложения Dial и Queue используются с опциями t и/или T.
Опция t позволяет вызываемой стороне перевести вызов с помощью сервисного кода.
Опция T позволяет вызывающей стороне перевести вызов с помощью сервисного кода.
Если не указать хотя бы одну из этих опций, сервисные коды перевода вызова не будут работать ни для одной из сторон вызова.
Обратите внимание на то, что исходящие вызовы пользователей 100-109 и 110 осуществляются через различных провайдеров, к тому же, пользователю 110 разрешены международные вызовы, а всем остальным пользователям — нет, эти условия должны быть соблюдены при переводе вызова.
Теперь нужно написать диалплан, который будет осуществлять сам перевод. По умолчанию перевод набирает введённый номер адресата в текущем контексте. Чтобы изменить это поведение, нужно установить значение переменной TRANSFER_CONTEXT, перевод будет выполняться в контексте имя которого указано в переменной TRANSFER_CONTEXT. Можно добавить эту переменную в раздел [globals] файла extensions.conf, тогда переменная TRANSFER_CONTEXT будет автоматически устанавливаться на каждом новом канале (в приведённом диалплане это уже сделано).
Ниже приведён сам контекст transfer, используемый для перевода вызовов:
Вкратце, контекст выполняет следующее:
— К опциям приложений Dial и Queue добавляется опция H, она позволяет завершить вызов сервисным кодом (в случае приложения Queue, опция H позволяет завершить вызов нажатием *, поэтому сервисный код отбоя вызова должен начинаться со *, чтобы его ввод работал и для приложения Dial и для приложения Queue). Выполнение этого сервисного кода во время управляемого перевода вызова позволит отменить перевод и вернуть вызов себе. В остальное время сервисный код будет недоступен, что предотвратит отбой вызоова из-за случайного ввода этого кода.
— К опциям приложения Dial добавляется опция g, она нужна для того, чтобы выполнение диалплана продолжалось после завершения приложения Dial (кроме случая, когда уничтожается канал звонящего).
— Определяется номер переводящего (переменная TRANSFERER) и его контекст (переменная TR_CONT). Перевод осуществляется в контексте пользователя, выполняющего вызов.
— Если переведённый вызов не был принят, проигрывается сообщение о том, что вызов будет переведён. Если переводящий всё ещё на линии, он поймёт, что перевод не удался и сможет вернуть вызов сервисным кодом.
— К CALLERID(name) добавляется префикс «XFER_FAIL: », чтобы пользователи видели, что это возврат после неудачного перевода.
— Если номер переводящего свободен, то производится попытка возврата вызова на номер переводящего.
— Если переводящий занят или не принял вызов, то вызов возвращается в последнюю очередь, в которую он входил.
— Если вызов ещё не был в очереди, он переводится на назначение по умолчанию (значение переменной TRANSFER_FAILOVER), в данном случае
В результате, перевод вызова осуществляется следующим образом:
неуправляемый перевод — во время разговора нужно набрать сервисный код ##, ввести номер адресата перевода и нажать # или подождать 4 секунды.
управляемый перевод — во время разговора нужно нажать *, ввести номер адресата перевода и нажать # или подождать 4 секунды. Если адресат перевода не принимает вызов, можно ввести сервисный код ** для отмены перевода и возврата вызова себе. Также можно положить трубку не дожидаясь ответа адресата, если он не ответит, вызов вернётся к переводящему или в очередь, если переводящий занят/не доступен/не взял трубку.
Если сервисный код перевода вызова был введён случайно, для возврата вызова нужно просто нажать # без ввода номера. Пользуйтесь таким переводом вызова и потери вызовов, связанные с неудачным переводом, будут сведены к минимуму.
Эффективное использование сервисных кодов перевода вызова в Asterisk
Многие знают о существовании в Asterisk сервисных кодов для управляемого и неуправляемого перевода вызова, далеко не все знают особенности их настройки. В этой статье будет описана настройка сервисных кодов для эффективного использования перевода вызова.
Настройка параметров сервисных кодов Asterisk
Настройки сервисных кодов Asterisk находятся в файле features.conf, по умолчанию, сервисные коды следующие:
управляемый перевод — не задан
неуправляемый перевод — #
отбой вызова — *
Как видите, управляемым переводом вообще нельзя пользоваться по умолчанию. Вносим в раздел [featuremap] файла features.conf:
Для применения изменений в файле features.conf, нужно выполнить команду в CLI Asterisk «features reload»:
asterisk -rx «features reload»
Теперь имеем следующие сервисные коды:
управляемый перевод — *
неуправляемый перевод — ##
отбой вызова — **
Схожесть кодов управляемого перевода и отбоя вызова не является проблемой, т.к. в описываемой схеме эти коды никогда не будут доступны пользователю одновременно.
В разделе файла features.conf [general] указываются различные параметы сервисных кодов, обратите внимание на следующие:
featuredigittimeout — максимальная задержка между вводом символов при наборе сервисных кодов в миллисекундах. Значение по умолчанию — 1000, т.е. 1 секунда. Для ввода сервисных кодов, предлагаемых в этой статье, секунды должно хватить. Для ввода более сложных сервисных кодов пользователям может периодически не хватать времени, поэтому рекомендуется увеличить значение этого параметра до 2000.
transferdigittimeout — максимальная задержка в секундах между вводом символов при наборе номера адресата перевода. Значение по умолчанию — 3. Для более комфортного ввода номера, нужно увеличить это время до 4-5 секунд.
Atxferdropcall — при значении по умолчанию «no», если при упарвляемом переводе переводящий кладёт трубку не дожидаясь ответа адресата перевода и адресат перевода так и не принимает вызов до достижения таймаута вызова (значение параметраatxfernoanswertimeout), Asterisk попытается вернуть вызов переводящему. Asterisk может пытаться вызвать переводящего определённое количество раз (значение параметра atxfercallbackretries) с определённым интервалом (значение параметра atxferloopdelay). Если установить значение параметра atxferdropcall равным «yes», то Asterisk не будет пытаться вернуть вызов переводящему после неудачного управляемого перевода. Нужно установить значение «yes», если обработака вызова после неудачного перевода вызова реализована средствами диалплана.
ПРИМЕЧАНИЕ: Стандартный механизм возврата вызова после неудачного управляемого перевода не очень хорош, т.к. он не проверяет, свободен ли абонент, на которого должен вернуться вызов, не позволяет выполнять диалплан и не имеет возможности перевести вызов кому-либо другому, если абонент, совершивший перевод, не берёт трубку. Рекомендуется использовать вместо этого возврат вызова, реализованный средствами диалплана.
Для примеров, приведённых в этой статье, использовались следующие значения параметров в разделе [general] файла features.conf:
[general]
featuredigittimeout = 2000
atxferdropcall = yes
transferdigittimeout => 4
Написание диалплана Asterisk для обработки перевода вызовов
Предположим, что для совершения вызовов используется следующий несложный диалплан:
[global]
TRANSFER_CONTEXT=transfer
DIAL_OPTS=Tt
DIAL_TIME=20
OUT_DIAL_OPTS=T
OUT_DIAL_TIME=180
Q_OPTS=t
DEF_PROV_CID=78888888888
PROV1_CID=71111111111
PROV2_CID=72222222222
TRANSFER_FAILOVER=queues,600,1
[sub-mixmonitor]
exten => s,1,GotoIf($[«$
same => n,Set(__RECORDING_FNAME=$
same => n,Set(__RECORDING_STARTED=true)
same => n,MixMonitor($
same => n,Set(AUDIOHOOK_INHERIT(MixMonitor)=yes)
same => n(end),Return
[local]
exten => _XXX,1,Gosub(sub-mixmonitor,s,1($
same => n,Dial(SIP/$
same => n,ExecIf($[«$
same => n,Hangup
exten => _XXX,hint,SIP/$
[queues]
exten => 600,1,Set(__PREVIOUS_QUEUE=$
same => n,Queue(reception,$
same => n,Hangup
exten => 601,1,Set(__PREVIOUS_QUEUE=$
same => n,Queue(sales,$
same => n,Hangup
[internal-default]
include => local
include => queues
exten => _8543XXXXXXXXX,1,Gosub(sub-mixmonitor,s,1($
same => n,Set(CALLERID(num)=$
same => n,Set(CALLERID(name)=)
same => n,Dial(SIP/def_prov/$
same => n,ExecIf($[«$
same => n,Hangup
[from-10X]
include => local
include => queues
exten => _8379XXXXXXXXX,1,Gosub(sub-mixmonitor,s,1($
same => n,Set(CALLERID(num)=$
same => n,Set(CALLERID(name)=)
same => n,Dial(SIP/prov1/$
same => n,ExecIf($[«$
same => n,Hangup
[from-110]
include => local
include => queues
exten => _8551XXXXXXXXX,1,Gosub(sub-mixmonitor,s,1($
same => n,Set(CALLERID(num)=$
same => n,Set(CALLERID(name)=)
same => n,Dial(SIP/prov2/$
same => n,ExecIf($[«$
same => n,Hangup
exten => _810Z.,1,Gosub(sub-mixmonitor,s,1($
same => n,Set(CALLERID(num)=$
same => n,Set(CALLERID(name)=)
same => n,Dial(SIP/prov2/$
same => n,ExecIf($[«$
same => n,Hangup
[from-trunk]
exten => 78888888888,1,Set(CDR(did)=$
same => n,ExecIf($[«$
same => n,Goto(queues,600,1)
exten => 71111111111,1,Set(CDR(did)=$
same => n,ExecIf($[«$
same => n,Goto(queues,601,1)
exten => 72222222222,1,Set(CDR(did)=$
same => n,ExecIf($[«$
same => n,Goto(local,110,1)
Пояснения к диалплану:
— вызовы пользователей 100-109 совершаются в контексте from-10X
— вызовы пользователя 110 совершаются в контексте from-110
— вызовы остальных пользователей совершаются в контексте internal-default
— входящие вызовы приходят в контекст from-trunk
— номер очереди сохраняется в переменную PREVIOUS_QUEUE перед входом в очередь — после вызова MixMonitor вызывается функция AUDIOHOOK_INHERIT, это нужно для того, чтобы запись продолжалась после перевода вызова
Для того, чтобы абоненты могли использовать сервисные коды перевода вызова, приложения, осуществляющие вызовы абонентов, должны использоваться с опциями разрешающими использование сервисных кодов для перевода вызова. В приведённом диалплане приложения Dial и Queue используются с опциями t и/или T.
Опция t позволяет вызываемой стороне перевести вызов с помощью сервисного кода.
Опция T позволяет вызывающей стороне перевести вызов с помощью сервисного кода.
Если не указать хотя бы одну из этих опций, сервисные коды перевода вызова не будут работать ни для одной из сторон вызова.
Обратите внимание на то, что исходящие вызовы пользователей 100-109 и 110 осуществляются через различных провайдеров, к тому же, пользователю 110 разрешены международные вызовы, а всем остальным пользователям — нет, эти условия должны быть соблюдены при переводе вызова.
Теперь нужно написать диалплан, который будет осуществлять сам перевод. По умолчанию перевод набирает введённый номер адресата в текущем контексте. Чтобы изменить это поведение, нужно установить значение переменной TRANSFER_CONTEXT, перевод будет выполняться в контексте имя которого указано в переменной TRANSFER_CONTEXT. Можно добавить эту переменную в раздел [globals] файла extensions.conf, тогда переменная TRANSFER_CONTEXT будет автоматически устанавливаться на каждом новом канале (в приведённом диалплане это уже сделано).
Ниже приведён сам контекст transfer, используемый для перевода вызовов:
Вкратце, контекст выполняет следующее:
— К опциям приложений Dial и Queue добавляется опция H, она позволяет завершить вызов сервисным кодом (в случае приложения Queue, опция H позволяет завершить вызов нажатием *, поэтому сервисный код отбоя вызова должен начинаться со *, чтобы его ввод работал и для приложения Dial и для приложения Queue). Выполнение этого сервисного кода во время управляемого перевода вызова позволит отменить перевод и вернуть вызов себе. В остальное время сервисный код будет недоступен, что предотвратит отбой вызоова из-за случайного ввода этого кода.
— К опциям приложения Dial добавляется опция g, она нужна для того, чтобы выполнение диалплана продолжалось после завершения приложения Dial (кроме случая, когда уничтожается канал звонящего).
— Определяется номер переводящего (переменная TRANSFERER) и его контекст (переменная TR_CONT). Перевод осуществляется в контексте пользователя, выполняющего вызов.
— Если переведённый вызов не был принят, проигрывается сообщение о том, что вызов будет переведён. Если переводящий всё ещё на линии, он поймёт, что перевод не удался и сможет вернуть вызов сервисным кодом.
— К CALLERID(name) добавляется префикс «XFER_FAIL: », чтобы пользователи видели, что это возврат после неудачного перевода.
— Если номер переводящего свободен, то производится попытка возврата вызова на номер переводящего.
— Если переводящий занят или не принял вызов, то вызов возвращается в последнюю очередь, в которую он входил.
— Если вызов ещё не был в очереди, он переводится на назначение по умолчанию (значение переменной TRANSFER_FAILOVER), в данном случае — очередь reception.
В результате, перевод вызова осуществляется следующим образом:
неуправляемый перевод — во время разговора нужно набрать сервисный код ##, ввести номер адресата перевода и нажать # или подождать 4 секунды.
управляемый перевод — во время разговора нужно нажать *, ввести номер адресата перевода и нажать # или подождать 4 секунды. Если адресат перевода не принимает вызов, можно ввести сервисный код ** для отмены перевода и возврата вызова себе. Также можно положить трубку не дожидаясь ответа адресата, если он не ответит, вызов вернётся к переводящему или в очередь, если переводящий занят/не доступен/не взял трубку.
Если сервисный код перевода вызова был введён случайно, для возврата вызова нужно просто нажать # без ввода номера.
Пользуйтесь таким переводом вызова и потери вызовов, связанные с неудачным переводом, будут сведены к минимуму.