Есть экстеншен такого вида exten=> _9XXXX/100,1,Dial(SIP/102)
Отрабатывает если CallerID звонящего "100"
Переношу диалплан в MySQL, весь диалплан работает, кроме _9XXXX/100. А точнее пропускается все без исключения, буд-то CallerID=108, 110 и т.д. Такое ощущения что Asterisk при считывании с БД пропускает "/100" а читает только "_9XXXX".
В чем может быть проблема? Либо это конкретный глюк Астера?
Имея диалплан
exten=> _9XXXX/100,1,Dial(SIP/102)
по нему любой, кто наберёт что-то пятизначное с 9-ки попадёт на устройство SIP/102, возможно это телефон. При этом пропускается все без исключения, буд-то CallerID=108, 110, хоть там вообще не будет CallerID. Потому что шаблон _9XXXX/100 описывае кому звонят, а не кто звонит, и он для меня загадка.
Что ты этим _9XXXX/100 хотел задать?
Счиаем что все 5значные номера с 9 нам надо отправить на SIP/102
| Цитата: |
| Other options for defining extensions include an option commonly referred to as the ex-girlfriend logic. This logic will match the dialed extension, whether it came from outside or inside, based on the callerid of the person calling it. For exmaple: exten => 123/100,1,Answer() exten => 123/100,2,Playback(tt-weasels) exten => 123/100,3,Voicemail(123) exten => 123/100,4,Hangup() This will match extension 123 and perform the following options ONLY if the Caller-ID Number of the calling user is 100. |
Правило базирующееся на callerid звонящего. Будет отрабатывать ТОЛЬКО если Caller-ID звонящего 100. Именно так как ты и описал, остальные - 108, 110 - игнорируются.
Если
| Цитата: |
| Такое ощущения что Asterisk при считывании с БД пропускает "/100" а читает только "_9XXXX". |
Диалплан
| Код: |
| exten => 123/100,1,Answer() exten => 123/100,2,Playback(tt-weasels) exten => 123/100,3,Voicemail(123) exten => 123/100,4,Hangup() |
будь они написаны в в extensions.conf, действовать будут (примерно так оно первоначально и работало) Но с переносом эестеншена в БД не работает именно конструкция 123/100 (его вторая часть будет игнорироваться, как буд-то ее вообще не существует)
Вот и хочу узнать может кто сталкивался с подобной ситуацией и в чем все-таки проблема
С самого начала пробовал _9XXXX/100 заменить "/" на "|" и "\" астериск сообщает что неверный экстеншен
Если нет - надо в баглист писать.
Посмотри командами, как читаются-пишутся выражения вида _9ХХХ/100 в таблицу диалплана? Дебаг и лог MySQL?
| Код: |
| mysql> select * from `asterisk`.`extensions_table` where exten='_91XXX/100'; +----+---------+-------------+----------+------+----------------------------+ | id | context | exten | priority | app | appdata | +----+---------+-----------+----------+------+----------------------------+ | 41 | office | _91XXX/100 | 1 | Dial | SIP/102 | +----+---------+-----------+----------+------+----------------------------+ |
По дебагу сип, Астер показывает что звонок просто идет на экстеншн _91XXX. Все больше прихожу к выводу что это баг.
Люди, неужели никто не пользуется Asterisk Realtime и не использует фильтрацию по CallerID?
Если у кого-то есть удачный опыт применения, версию Asterisk и аддона в студию!!
Более того нашел еще один глюк Если я делаю такую конструкцию exten 101/108 , то до экстеншена 101 вообще никто не может дозвониться, даже 108. Asterisk+Realtime = ГЛЮКИ
Хоть кто-нибудь держал конфигурацию Asterisk в mysql-e ?
Added after 1 hours 14 minutes:
Вопрос снимается. Это баг и похоже, что до сих пор не решенный.
Так что аккурано связывайтесь с Realtime !!
Всем удачи!