2014-01-22 4 views
2

Возможно ли зарегистрировать SIP-запросы в базе данных в звездочке? Я заинтересован в этих деталях:Как регистрировать запросы вызова (SIP) в звездочке?

  • метка времени
  • метод SIP
  • код состояния
  • номер источника/расширение
  • номер адресата/расширение

Я уверен, что это можно перевести события queue_log в SIP-запросы и получить от него вышеуказанную информацию. Однако, поскольку не каждый вызов проходит через очереди вызовов, это решение не работает для меня.

Возможно, этого можно достичь с помощью AMI? Или написать пользовательский диалплан? Поделитесь своими мыслями по этому вопросу.

ответ

4

Нет способа сделать это.

Asterisk не записывает сообщения sip, если вы не включили отладочную съемку.

Если вам нужен контроль над уровнем сообщений, ознакомьтесь с проектом kamailio/opensips.

+0

В принципе, я хочу предоставить клиенту свои события вызова в реальном времени. Решение выполнено, но наши текущие события не содержат информации о расширении, которое вызвало вызов в случае входящих вызовов. Вы можете видеть только стандартный внешний номер. Мы используем kamailio, но я как бы боюсь пойти туда и начать переписывать макросы - не хочу вызывать простои в моей инфраструктуре для работодателей, потому что я новичок в области камаилио. Вот почему я хотел решить это так, что вряд ли вызовет большие проблемы, если что-то пойдет не так. – reederz

+1

Вы можете контролировать вызовы через dialplan или через ami-события. Но звонки - это не одно сообщение. Каждый вызов имеет гораздо больше, чем одно сообщение для настройки. Kamailio имеет дело с сообщениями. Asterisk занимается переадресацией вызовов и расширений.Ни в коем случае не контролируйте ни одно сообщение в звездочке. Если вы не уверены, у вас есть эксперт по найму. – arheops

4

Раньше я работал с клиентом, который требовал очень полной статистики в реальном времени. Чтобы все было правильно, нам пришлось объединить CDR, CEL и queue_logs. В конце концов это была очень сложная система, но в то время мы не видели другого пути. Ну, мы сделали, но это было невозможно.

Один из самых простых вопросов, которые вы можете задать: Кто (A) назвал, кто (B), и кто ответил на вызов (C) в конце. Если вы можете ответить на этот вопрос, вы можете в принципе ответить, какой клиент (A), вызывает расширение (B), которое может отражать интерес клиента. Чтобы узнать, где произошла рабочая нагрузка, вы должны иметь окончательное расширение (C).

Проще всего это звучит очень сложно, в зависимости от настройки клиента. Если у вас есть смешанные технологии, такие как ISDN для исходящих звонков, и SIP (звездочка/freeswitch) для входящих (внутрикорпоративных) вызовов, вы можете обнаружить, что вообще нет полезной записи о вызовах.

Даже для входящей SIP-телефонии я могу сказать вам, что есть сценарии, где просто найти правильные расширения A, B, C - это очень сложно !!! Во-первых, вы должны знать, что Asterisk внутренне знает о двух так называемых «ногах», где две ноги представляют собой мост между двумя каналами (пожалуйста, исправьте меня, если я ошибаюсь). Я не эксперт здесь, но считаю, что две конечные точки говорят друг с другом. В этой терминологии нет «первоначально называемого расширения B». Кроме того, CEL и CDR не устраняют это. В CDR есть поля «dst» и «src», но действительно «канал» и «dstchannel» имеют для вас большую ценность. «Dstchannel» иногда выглядит как «SIP/dialnumber @ foobar», но только если ваши учетные записи SIP каким-то образом относятся к указанному номеру (extension = dialnumber). Обратите внимание, что клиенты часто не заботятся о различии между расширением или номером набора, но в SIP вам все равно.

Что действительно помогает, если вы используете пользовательские переменные CDR. Настройте звездочку для использования драйвера «custom_cdr» для ведения журнала CDR и, возможно, «custom_cel» для ведения журнала CEL. Затем вы можете установить переменные CDR в своем диалплане, и они автоматически записываются в базу данных CDR/CEL (например, ODBC).

В качестве последнего момента, чтобы подумать: подумайте о A, B и C, чтобы быть людьми. Пусть A вызов B.Пусть B положит A на удержание и спросит у человека C, может ли она взять на себя из-за своего опыта. Переведите вызов от A < -> B до A < -> C (B зависает). Сколько CDR и сколько CEL вы думаете, что получаете от этого? И как заполняются поля? В CDR это похоже на то, что A разговаривал с B в течение всего времени. Только взглянув на CEL, вы заметите, что произошло событие TRANSFER, которое дает вам подсказку. (Извините, если из моей памяти это может быть совершенно иначе).

С этим довольно страшным ответом я настоятельно призываю вас потратить очень много времени на требования техники, а не начинать со звездочки и камалио. Спросите, какие варианты использования клиент хочет покрыть вашим решением. Поверь мне, ты не можешь все покрыть. Подумайте о наличии гибкого формата данных для хранения вашей статистики. Подумайте о базах данных на основе документов, таких как MongoDB.

Если вы хотите начать с чистого Asterisk, вы должны использовать AMI. Возможно, некоторые пользовательские процессы прослушивают события, объединяют их и делают их доступными через кеш, поэтому вам не нужно запрашивать AMI и загружать Asterisk.

Надеюсь, это поможет, но, вероятно, вы пытаетесь достичь чего-то совершенно другого. :)

Удачи.

+0

Это дало мне несколько идей. Моя первоначальная мысль заключалась в том, чтобы передать клиенту любую информацию, которую мы используем для выставления счетов. В основном, я просто отправлял им события, которые модуль kamailio вносит в базу данных (именно по этой причине я выбрал формат SIP-подобного события). Только после этого я узнал, что мы не регистрируем расширение адресата, когда вышеупомянутый клиент находится на получающей стороне. Клиенту необходимо знать, какое расширение подбирает вызов, потому что они хотят делать некоторые статистические данные о своих сотрудниках, а что нет. – reederz

+0

Как бы то ни было, приложение работает уже какое-то время - единственное, чего не хватает, это расширение назначения. Вот почему я направляюсь к «редактированию kamailio.cfg, чтобы собрать этот дополнительный бит информации и редактировать диалплан, чтобы предоставить эту информацию для решения kamailio». Я думаю, если бы я начал проект заново, я мог бы поступить иначе. дизайн событий с AMI в качестве основы, а не kamailio acc – reederz

+0

Вопрос в этом вопросе состоял в том, чтобы найти простой взлом для решения моей упомянутой проблемы. Я думал, что звездочка может предоставить события SIP в случае входящих вызовов, а остальные случаи будут покрыты уже существующим решением kamailio acc. – reederz

2

Не могли бы вы прояснить одну вещь. Вы хотите только журналы? Если затем выполните следующие действия,

  1. открытый sip.conf и сделать sipdebug = да так, что потягивать сообщения записываются в файл отладки
  2. открытым asterisk.conf и проверить astlogdir. он даст вам местоположение отладочного файла. Если вы хотите, вы можете изменить местоположение.
  3. open logger.conf и добавить типы журналов в любой журнал, который вы хотите иметь при отладке => например. debug => notice, warning, error, verbose, dtmf
  4. Перезапустите процесс звездочки, чтобы изменения вступили в силу.

Помимо этого, если мне нужно хранить дополнительные данные или если я хочу что-то сделать с вызовом, я пишу свой собственный абонентский набор с помощью специальной функции, и я использую базу данных mysql для хранения моих необходимых данных. Если вы хотите написать собственное приложение, в вашей системе должны быть установлены звездочка и звездочка, и вы начнете писать собственное приложение в директории asterisk-addon/apps и поместите общую библиотеку в lib или lib64, в зависимости от типа вашей системы. Не забудьте перезапустить звездочку после внесения любых изменений. Дайте мне знать, смогу ли я устранить ваши сомнения.

+0

Нет, меня интересуют SIP-подобные события вызова (описанные в вопросе), чтобы я мог предоставить данные о звонках в реальном времени клиенту. Журналы, скорее всего, были бы непригодны в этом случае. – reederz

+0

На самом деле я пишу свое приложение для звездочки в зависимости от требования, поэтому я создаю свой собственный cdr. Я не знаю вашу телефонную линию или сценарий звонка. Но если вы хотите, то можете сказать вам примерный сценарий, что я делаю, если мне нужно сделать исходящий звонок и зарегистрировать данные. – niloydebnath

+0

, но CDR - это не то же самое, что и события вызова (если только я не понимаю концепцию). Я мог бы очень хорошо отправить CDR клиенту после его создания - проблема в том, что CDR генерируются после завершения сеанса вызова. Другими словами, клиент не получит информацию о своем звонке в реальном времени. Вот почему я хочу отправлять события стиля SIP клиенту, чтобы они могли создавать приложения в реальном времени на основе этих событий. Пример сеанса: | t0 | INVITE 180 (кольцо) | t1 | INVITE 180 (кольцо) | t2 | INVITE 200 (ответ) | t3 | BYE 200 (hangup) – reederz

2

Давайте соединим сервер звездочку с помощью звездочку -r

затем введите команду глотнуть набор отладки на. Вы можете найти исполняемые журналы и весь запрос sip.