Разработчику системы анализа звонков понадобилось что бы в CDR в поле accountcode заполнялось номером транка на который поступил звонок.
Для этого в настройках каждого транка мы прописали в outgoing Settings опцию accountcode=<номер транка>
В результате получили неадекватное заполнение поля Account в CDR записях - теперь все входящие на все транки помечаются номером только одного транка - того который в списке выше всех.
Подскажите с чем это может быть связано?
если у всех транков одинаковый адрес, то выбирается первый транк.
дальнейший поиск не производится.
если нужна селекция, надо смотреть, что отличается в INVITE и писать код.
Задан: 2015-07-29 09:43:14 +0400
Просмотрен: 1,079 раз
Обновлен: Jul 30 '15
Проект компании "АТС Дизайн"
Asterisk® и Digium® являются зарегистрированными торговыми марками компании
Digium, Inc., США.
IP АТС Asterisk распространяется под лицензией
GNU GPL.
Может одинаковый контекст? Я гадаю на гуще ;)
Out ( 2015-07-29 10:44:08 +0400 )редактироватьЕсли "НА который поступил звонок", то почему OUTGOING settings?
glukinho ( 2015-07-29 12:30:36 +0400 )редактироватьво freepbx если стоит type=friend неважно входящаяя это секция или исходящая
meral ( 2015-07-30 01:36:36 +0400 )редактироватьКонтексты разные.
У нас стоит type=friend на всех этих транках
Все транки у нас делятся условно на две группы: 1 транки со шлюзами GSM и аналоговыми 2 транки с провайдером Манго - именно с этими манговскими транками и происходит проблема.
Что за код надо писать?
Eduard1 ( 2015-07-30 10:28:15 +0400 )редактироватьmeral, что подразумевается под "одинаковый адрес"? IP-адрес? Если да, то как тогда корректно отображается accountcode для входящих линий через PSTN и GSM-шлюзы? Ведь у них тоже по одному IP-адресу на несколько линий.
Eduard1 ( 2015-07-30 10:39:18 +0400 )редактироватьесли ip-адреса для двух и более транков совпадает, берется первая секция. шлюзы наверно разные адреса имеют,не? sip show peers смотрите. надо написать контекст который по вторичным признакам, если они есть, разбросает accountcode. предварительно надо проверить отличаются ли инвайты на "разные" транки. если нет - то это все один транк и то, что вы его написали в разных секциях - ваша проблема.
meral ( 2015-07-30 14:21:31 +0400 )редактироватьИмеется один PSTN шлюз c четырьмя FXO портами и одним IP-адресом, но на нем такой проблемы нет.
Чем можно проанализировать INVITE с проблемных транков? Tcpdump для этого сгодится?
Eduard1 ( 2015-07-30 17:48:18 +0400 )редактироватьsip set debug ip ip_here
meral ( 2015-07-30 18:47:44 +0400 )редактироватьЯ включил дебаг и вот что я получил:
[2015-08-04 10:43:24] VERBOSE[11154] chan_sip.c: <FF><--- SIP read from UDP:81.88.86.11:5060 ---> <FF>INVITE sip:74993220538@194.247.191.31:5060 SIP/2.0 <FF>Via: SIP/2.0/UDP 81.88.86.11:5060;branch=z9hG4bK64c2.08ddb883.0
То есть я вижу что в инвайте корректный номер - тот на который я действительно позвонил. Но через несколько строк лога появляется вот такая информация:
[2015-08-04 10:43:24] VERBOSE[11154] chansip.c: Sending to 81.88.86.11:5060 (NAT) [2015-08-04 10:43:24] VERBOSE[11154][C-00000462] chansip.c: Sending to 81.88.86.11:5060 (NAT) [2015-08-04 10:43:24] VERBOSE[11154][C-00000462] chansip.c: Using INVITE request as basis request - ZWE2YjFjNmY3OGQ2MGU5ZDVjMmQ0NjIyNmQxZGVlMGE. [2015-08-04 10:43:24] VERBOSE[11154][C-00000462] chansip.c: Found peer 'Mango-Trunk-74993220124' for '79015013694' from 81.88.86.11:5060
Тут вдруг всплывает номер 74993220124. Как так?
Eduard1 ( 2015-08-04 12:11:35 +0400 )редактироватьвсплывает не номер, а ПЕРВЫЙ ТРАНК. начинайте читать что вам пишут. астериск входящий транк по адресу вычисляет. и то, что вы 10 транков с одним адресом завели - его не волнует.
meral ( 2015-08-04 17:24:32 +0400 )редактироватьКак быть, если у меня один адрес (NAT) и у провайдера телефонии один адрес?
Eduard1 ( 2015-08-04 17:38:17 +0400 )редактироватьнаписать контекст который выставит accountcode по входящему номеру. ну или воспользоватся аналогичным поелм в inbound routes
meral ( 2015-08-04 19:12:48 +0400 )редактировать