[asterisk-dev] Attended transfers in queue_log

[Atis Lezdins]

On Fri, Jun 13, 2008 at 1:07 AM, Mark Michelson <mmichelson at digium.com> wrote:
> Atis Lezdins wrote:
>> On Thu, Jun 12, 2008 at 7:47 PM, Mark Michelson <mmichelson at digium.com> wrote:
>>> I just finished merging a change into the trunk branch which corrects a
>>> long-standing deficiency of the queue_log: the inability to log attended transfers.
>>>
>>> A bit of background: prior to the merge, a blind transfer made by a queue member
>>> would show up in the queue_log as a TRANSFER event. Attended transfers, however,
>>> due to the limitations of what information was available to app_queue, did not
>>> log a TRANSFER event. Instead, they appeared as a COMPLETECALLER event. With the
>>> recent addition of a "fixup" phase to datastores during channel masquerades, I
>>> realized that this could facilitate a means by which to correctly log an
>>> attended transfer in the queue_log. Yesterday, I created a branch to make this a
>>> reality and this morning I merged the branch into trunk.
>>>
>>> Now the question arises: should this change also be merged into 1.4? My thinking
>>> is that the majority of users would be very happy to see attended transfers
>>> properly logged in the queue_log. The big thing holding me back right now is
>>> that there are many third-party applications that use the data in the queue_log
>>> to generate statistics. While I don't know of the specifics of these
>>> applications' internals, I know that any sort of change to what is expected may
>>> cause problems. To any who have written such apps, would such a change cause a
>>> problem? Would it actually be helpful? Thanks in advance for your replies.
>>
>> Hello,
>>
>> Just saw the commit. No opinion upon merging in 1.4 (however this
>> sounds like a feature).
>>
>> I just wanted to add, that maybe it would be better to somehow
>> separate blind and attended transfers. Btw, from my understanding of
>> code, queue log entry will have duration until completion  of attended
>> transfer, wouldn't it be better to use duration until start of
>> attended transfer? Or just log both, that way it would be distinct
>> from blind transfer.
>>
>> Regards,
>> Atis
>
> It would be trivial to change the names of the TRANSFER messages in the log to
> TRANSFER(BLIND) and TRANSFER(ATTENDED) or something similar in trunk. If I were
> to backport this to 1.4 though, I would not add the clarification due to the
> third party tools which use the queue_log as their input source.

Sure, that's why i asked for this, as it seemed trivial. Do I
understand correctly that it will be the same way as COMPLETE(CALLER)
and COMPLETE(AGENT), if so it would be good.

As for 1.4, it probably would be good to leave TRANSFER and
TRANSFERATTENDED, and rename TRANSFER to TRANSFERBLIND for 1.6(.1).

>
> Regarding the logging of various times, that will be very cumbersome to try to
> implement. The problem at the root of it all is that app_queue loses complete
> control of the thread once the queue caller and the queue member are bridged.
> This means that getting information back to app_queue about things like when the
> queue member initiated the transfer is next to impossible. It may be possible to
> implement a datastore on the queue member's channel, but the problem is that the
> datastore would have to be globally accessible since it may need to be accessed
> by any of the files that implement transfer code as well as app_queue.
> Furthermore, getting the time correct may be tricky if the queue member attempts
> a transfer but fails. Also, if local channels are used for queue members, then
> that opens a new can of worms regarding where the datastore resides.
>
> Separating the times is certainly possible, but unless it is absolutely
> necessary, the effort and potential nastiness that may result is not worth it in
> my view.

Oh, i actually read the patch now, and understood this. I just asked,
because i thought it would be simple :) Anyway, that's what CDR is
for.

I have created a backport
(http://ftp.iq-labs.net/queue_log_atxfer/queue_log_atxfer-1.4.21.patch)
and will ask our tester to break this next week. And the link here is
supposed to encourage anyone else to test this.

Regards,
Atis

-- 
Atis Lezdins,
VoIP Project Manager / Developer,
atis at iq-labs.net
Skype: atis.lezdins
Cell Phone: +371 28806004
Cell Phone: +1 800 7300689
Work phone: +1 800 7502835