Разработчику системы анализа звонков понадобилось что бы в CDR в поле accountcode заполнялось номером транка на который поступил звонок.
Для этого в настройках каждого транка мы прописали в outgoing Settings опцию accountcode=<номер транка>
В результате получили неадекватное заполнение поля Account в CDR записях - теперь все входящие на все транки помечаются номером только одного транка - того который в списке выше всех.
Подскажите с чем это может быть связано?
если у всех транков одинаковый адрес, то выбирается первый транк.
дальнейший поиск не производится.
если нужна селекция, надо смотреть, что отличается в INVITE и писать код.
Задан: Jul 29 '15
Просмотрен: 1,093 раз
Обновлен: Jul 30 '15
Проект компании "АТС Дизайн"
Asterisk® и Digium® являются зарегистрированными торговыми марками компании
Digium, Inc., США.
IP АТС Asterisk распространяется под лицензией
GNU GPL.
Может одинаковый контекст? Я гадаю на гуще ;)
Out (Jul 29 '15)editЕсли "НА который поступил звонок", то почему OUTGOING settings?
glukinho (Jul 29 '15)editво freepbx если стоит type=friend неважно входящаяя это секция или исходящая
meral (Jul 29 '15)editКонтексты разные.
У нас стоит type=friend на всех этих транках
Все транки у нас делятся условно на две группы: 1 транки со шлюзами GSM и аналоговыми 2 транки с провайдером Манго - именно с этими манговскими транками и происходит проблема.
Что за код надо писать?
Eduard1 (Jul 30 '15)editmeral, что подразумевается под "одинаковый адрес"? IP-адрес? Если да, то как тогда корректно отображается accountcode для входящих линий через PSTN и GSM-шлюзы? Ведь у них тоже по одному IP-адресу на несколько линий.
Eduard1 (Jul 30 '15)editесли ip-адреса для двух и более транков совпадает, берется первая секция. шлюзы наверно разные адреса имеют,не? sip show peers смотрите. надо написать контекст который по вторичным признакам, если они есть, разбросает accountcode. предварительно надо проверить отличаются ли инвайты на "разные" транки. если нет - то это все один транк и то, что вы его написали в разных секциях - ваша проблема.
meral (Jul 30 '15)editИмеется один PSTN шлюз c четырьмя FXO портами и одним IP-адресом, но на нем такой проблемы нет.
Чем можно проанализировать INVITE с проблемных транков? Tcpdump для этого сгодится?
Eduard1 (Jul 30 '15)editsip set debug ip ip_here
meral (Jul 30 '15)editЯ включил дебаг и вот что я получил:
[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 (Aug 4 '15)editвсплывает не номер, а ПЕРВЫЙ ТРАНК. начинайте читать что вам пишут. астериск входящий транк по адресу вычисляет. и то, что вы 10 транков с одним адресом завели - его не волнует.
meral (Aug 4 '15)editКак быть, если у меня один адрес (NAT) и у провайдера телефонии один адрес?
Eduard1 (Aug 4 '15)editнаписать контекст который выставит accountcode по входящему номеру. ну или воспользоватся аналогичным поелм в inbound routes
meral (Aug 4 '15)edit