[asterisk-users] CEL logging and queue APP_START/END, maybe an issue?

[Matthew Jordan]

On Sun, Jun 30, 2013 at 4:24 PM, Fabio Moretti <fmoretti at tecytal.com> wrote:

>  Hi, I'm still doing experiment with CEL and recently I've noticed that if:
>
> 1- call enter in the pbx
> 2- call enter a queue
> 3- call get answered
> 4- the operators call directly another queue, using  the queue number
> 5- the call get answered
> 6- the call end
>
> the point 4 does not generate a correct logging. In my case I have the
> extension 1006 answering the call with linkedid 1371568201.486360, then
> call queue number 21. I get only a BRIDGE_UPDATE event:
>
> '1812621', 'BRIDGE_UPDATE', '2013-06-18 12:11:31', 'ISS23071100', '23071100', '23071100', '24872939', '', '21', 'from-internal', 'Local/1006 at from-queue-00034a00;2', '', '', '', '', 'Queue', '21,tr,,', '3', '', '1371568269.486380', '1371568201.486360', 'Local/714126 at from-queue-00034a04;1', '', '', ''
>
>
> here you can se the extension called (21), the source channel
> (Local/1006 at from-queue-00034a00), the peer
> (Local/714126 at from-queue-00034a04) and especially you can see that the
> app name is "queue".
> After this event I have only an APP_END for queue number 21, but no
> CHAN_START/END for the peer channel, no queue events, nothing.
> This is if I follow the call with linkedid 1371568201.486360.
> If I search the uniqueid of the BRIDGE_UPDATE as linkedid
> (1371568269.486380) I get the whole queue 21 call history, as I expected to
> find in the original call linkedid.
>
> I think that because the call is the same the linkedid shouldn't change at
> all, but in this case the cel logging is generating a "sub" cel, is this by
> design? I'm supposed to check if the current event have generate a sub-cel
> to reconstruct the call histoery completely?
> And if it is by design, isn't a bug put the queue APP_START event in the
> sub-cel linkedid and the APP_END in the original linkedid?
>
> If someone can have a look I've attached the CSV for the two linkedids..
>
>
Nope, this is entirely expected.

A BRIDGE_UPDATE CEL event occurs when a masquerade happens and the
participants in a bridge have been altered - that is, a channel came in and
pushed one of the channels in the bridge out. In this particular case,
Local/714126 at from-queue-00034a04;1 has replaced the channel
Local/1006 at from-queue-00034a00;2 was bridged with, SIP/1006-00007705. You
can see that SIP/1006-00007705 is disposed of immediately following this
event.

When a BRIDGE_UPDATE happens, you have to start pulling the records from
the new channel in with whoever is still in the bridge. This usually means
that someone's linkedid changed (as the participants changed). linkedids
absolutely do change on a channel in this scenario - when two channels are
bridged (which is what has happened when the BRIDGE_UPDATE occurs - the
Local channel pushed the SIP channel out), the linkedids are updated on the
participants based on who had the older linkedid. In this case,
Local/714126 at from-queue-00034a04;1's linkedid was updated. So if you want
to know everything that happened with that Local channel, you have to tie
together both the current linkedid as well as what was its previous
linkedid.

When you're dealing with CEL, you're operating on a level much closer to
what Asterisk is actually doing with its channels. This means having to
deal with Local channel pairs and - more importantly - masquerades. This is
a whole lot more powerful than CDRs, but does mean that you have to do some
bookkeeping to keep track of the channel states.

On a side note, the fact that masquerades are hard and tend to require
people to do lots of updates was a driving factor in the development
efforts that went on in 12. Masquerades are now an implementation detail,
so in the future, you won't have to deal with BRIDGE_UPDATE.

Matt

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20130701/e6444b25/attachment.htm>