Asterisk: callfiles и Realtime

Поскольку я использую Realtime, кажется, что файлы вызовов не работают должным образом. Когда файл вызова выполняется, телефон звонит, как и ожидалось. Но астериск (v 1.6) сразу бросает трубку как отвечает на звонок.

Мой файл вызова:

Channel: SIP/1
Callerid: <123>
Context: test
Extension: 100

Мои расширения в реальном времени:

cont|ext|pr|App
----+---+-+---------
test|100|1|Answer
----+---+-+---------
test|100|2|SayNumber(123)

Сообщение об ошибке в клиентском интерфейсе:

Channel 'SIP/1-0000001' sent into invalid extension 's' in context 'default', but no invalid handler

Зашито, что когда я меняю расширение в таблице выше со 100 на s, все работает нормально.

У кого-нибудь есть подсказка?

Обновлять:

К сожалению, и команда mv не решает проблему. (Я также добавил еще одну строку в свой файл вызова Priority: 1.)

Вот файлы:

extconfig.conf

sipusers => mysql,general,sip_users
sippeers => mysql,general,sip_users
extensions => mysql,general,extensions 

sip.conf

[general]
language=en
bindport=5060
context=default
canreinvite=no
tos=throughput
nat=yes

person SIPly    schedule 12.06.2011    source источник


Ответы (1)


Что ж, я не знаком с Realtime, но размещение сгенерированных sip.conf и extensions.conf было бы полезно (по крайней мере, в соответствующих разделах).

Однако мой первый инстинкт заключается в том, что вы используете cp для копирования файлов вызовов для звездочки, что не является атомарной операцией (файлы копируются построчно), что может привести к тому, что звездочка выполнит не совсем полный файл вызова.

Используйте команду mv, которая является атомарной операцией и гарантирует, что asterisk работает со 100% полным файлом вызовов.

Причина, по которой я подозреваю, что это проблема, заключается в том, что ваш файл вызова верен, но если он начинает выполняться только с 2 строками, по умолчанию любой входящий вызов будет идти на расширение «s» контекста по умолчанию, и если он читается в третья строка, она перейдет к расширению 's' вашего тестового контекста.

Странная ошибка, чтобы быть уверенным.

person gnxtech3    schedule 13.06.2011