CDR не пишется после hangup (до - нормально пишется)

[Felt]

Если вызвать Set(CDR(...)=...) перед тем как положили трубку - эти данные попадают в базу. То, что в экстеншине h меняет CDR - уже не записывается в базу.

Упростил проблему до такого примера:

Код: выделить все

[incoming]

exten => _X.,1,Set(CDR(userfield)=test1)
same => n,Dial(SIP/500000/89610000000,120,tT)

exten => h,1,Set(CDR(is_incoming)=1)
same => n,Set(CDR(userfield)=test2)

В итоге в таблицу попадает запись userfield=test1, а is_incoming=0 (0 - значение по умолчанию для этого поля).

Asterisk 13.1.0~dfsg-1.1ubuntu4
Настроено через ODBC.

Код: выделить все

/etc/asterisk/cdr.conf
[general]
enable=yes
unanswered=yes


В логах ошибок нет.

Код: выделить все

/etc/asterisk/cdr_adaptive_odbc.conf
[global]
dsn=asterisk
dispositionstring=yes
connection=asterisk
loguniqueid=yes
table=cdr
alias is_incoming => is_incoming
alias in_callerid => in_callerid
alias userfield => userfield
alias start => calldate

Добавил на всякий случай alias is_incoming => is_incoming и alias userfield => userfield.

Что еще сказать. Пользовательских полей несколько, все они пишутся успешно при вызовах до того как положили трубку. В exten => h уже не пишутся.

Код: выделить все

ats-asterisk*CLI> odbc show

ODBC DSN Settings
-----------------

  Name:   asterisk
  DSN:    MySQL-asterisk
    Last connection attempt: 1970-01-01 07:00:00
  Pooled: No
  Connected: Yes

В чем причина? На другом сервере пишется нормально в h, но там старая 11 версия Астериска. Настройки сверил - одинаковые по этим пунктам.

[Wapo]

Спасибо - бум знать еще об одной запятой в 13-ветке ( не считая того, что она пишет на каждый диал отдельную запись в cdr т.е.
same => n,Dial(SIP/100,10)
same => n,Dial(SIP/101,10)

помещает 2 записи)

[Felt]

Решил посмотреть бесконечный changelog начиная с моей версии 13.1.0 и нашёл упоминание про двойную запись. Не совсем понял фишка это или баг:

2015-06-12 14:28 +0000 [b8bc15286f] Matt Jordan <mjordan@digium.com>

* main/cdr: Copy context/exten on chained CDRs for parallel dials in subroutines

When a parallel dial occurs, a new CDR will be created for each dial
attempt that is made. In most circumstances, the act of creating each
CDR in the chain will include a step that updates the Party A snapshot,
which causes the context/extension of the Party A to be copied onto the
CDR object.

However, when the Party A is in a subroutine, we explicitly do *not*
copy the context/extension onto the CDR. This prevents the Macro or
GoSub routine name from blowing away the context/extension that the
channel was originally executing in. For the original CDR, this is not a
problem: the original CDR already recorded the last known 'good' state
of the channel just prior to it going into the subroutine. However, for
newly generated CDRs in a chain, there is no context/extension set on
them. Since we are in a subroutine, we will never set the Party A's
context/extension on the CDR, and we end up with a CDR with no
destination recorded on it.

This patch updates the creation of a chained CDR such that it copies
over the original CDR's context/extension. This is the last known "good"
state of the CDR, and is a reasonable starting point for the newly
generated CDR. In the case where we are not in a subroutine, subsequent
code will update the location of the CDR from the Party A information;
in the case where we are in a subroutine, the context/extension on the
original CDR is the correct information.

ASTERISK-24443 #close

Change-Id: I6a3ef0d6e458d3b9b30572feaec70f2964f3bc2a

[Felt]

А вот очень напоминает упоминание моей проблемы:

2016-01-02 10:23 +0000 [153547a9b1] Matt Jordan <mjordan@digium.com>

* main/cdr: Set the end time on a CDR if endbeforehexten is Yes

Prior to this patch, the CDR engine attempted to set the end time on a CDR
that was executing hangup logic and with endbeforehexten set to Yes by
calling a function that inspects the properties on the Party A snapshot to
determine if we are ready to set the end time. That always failed. This is
because a Party A snapshot is not updated for CDRs that are executing hangup
logic with endbeforehexten=Yes.

Instead of calling a function that looks at the Party A snapshot, we just
simply set the end time on the CDR. This is safe to call multiple times, and is
safe to call at this point as we know that (a) we are executing hangup logic,
and (b) we are supposed to set the end time at this point.

ASTERISK-25458

Change-Id: I0c27b493861f9c13c43addbbb21257f79047a3b3

[Felt]

Последний кусок спама в тему обновления CDR при завершении звонка.
В тот же день, что и изменение в предыдущем сообщении было закоммичено такое:

2016-01-02 10:26 +0000 [1087b0c6ed] Matt Jordan <mjordan at digium.com>

* main/cdr: Allow setting properties on a finalized CDR if it is the last one

Prior to this patch, we explicitly disallowed setting any properties on a
finalized CDR. This seemed like a good idea at the time; in practice, it was
more restrictive.

There are weird and strange scenarios where setting a property on a finalized
CDR is definitely wrong. For example, we may Fork a CDR, finalizing the
previous one, then change a property. In said case, the old CDR is supposed
to now be 'immutable' (so to speak), and should not be updated. From the
perspective of the code, a forked CDR that is finalized is just finalized.
Hence why we decided these should not be updated.

In practice, it is much more common to want to set a property on a CDR in
the h extension or in a hangup handler. Disallowing a common scenario to make
an esoteric behaviour work isn't good. This patch fixes this by allowing
callers to set a property IF we are the last CDR in the chain. This preserves
the finalized CDR if it was forked, while allowing the more common case to
function.

ASTERISK-25458 #close

Change-Id: Icf3553c607b9f561152a41e6d8381d594ccdf4b9

[Felt]

По номеру проблемы 25458 нашел задачу в Жире Астериска:
https://issues.asterisk.org/jira/plugin ... RISK-25458

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

[Wapo]

Я, когда увидел дублирование, полез внимательно читать conf-файл, но опции, которые там указаны НИКАК не влияют на конечный результат - такое ощущение, что разработчик многое закладывал изначально, но потом просто махнул рукой.

[Felt]

Судя по переписке в задаче в Jira (ссылка в предыдущем сообщении) параметр endbeforehexten все же должен работать:
endbeforehexten=no - создаёт две записи в CDR и при обработке в hangup меняет во второй.
Правда в задаче последнее сообщение с примером, что не работает - в CDR записей две и обе без изменений сделанных в h.

endbeforehexten=yes - не создаёт дублирующих записей в CDR.
Но тоже судя по переписке не даёт изменять в h. Типа закрытие CDR происходит при разрыве бриджа перед h.

(кстати, как включить, чтобы в консоли и в логе отображался момент записи в CDR и сам запрос?)

Не очень понятно решена ли задача. В переписке говорится, что ошибки присутствуют, разработчик из Дигиума говорит решить сложно. Но тем не менее задача числится как закрытая и патч вошёл в исходники. Правда непонятно когда именно и в какую версию. Да и после публикации исправления отписались, что созданный патч так и не работает. Ничего не понял в итоге.

У меня на разных клиентских серверах есть более поздние версии: 13.9 и 14.х. Если найду время - проведу эксперимент и отпишусь исправлена ли ошибка в 13.9 и в 14-й версиях. Или если кто-то уже знает - сообщите сразу.

[asofts.ru]

Из любопытства посмотрел работу записи в CDR в h по некоторым версиям:
Asterisk 11.7.0 - меняет все поля
Asterisk 13.1.0 - не меняет ни стандартные поля (в том числе userfield не меняет), ни созданные самостоятельно поля не меняет
Asterisk 13.9.1 - стандартные поля (в том числе userfield не меняет), но созданные самостоятельно поля меняет
Asterisk 14.3.0 - стандартные поля (в том числе userfield не меняет), но созданные самостоятельно поля меняет

[fecyt]

Столкнулся с этой же проблемой, единственное, что пришло в голову это использоваться в Dial опцию g, и следующим приоритетом записывать CDR. Но в данном случае она не запишется, если вызывающая сторона кладет трубку, а других идей пока не придумал. Пробовал на версиях 13.2.0 и 11.25.1.