<div dir="ltr">On Sun, Jun 30, 2013 at 4:24 PM, Fabio Moretti <span dir="ltr"><<a href="mailto:fmoretti@tecytal.com" target="_blank">fmoretti@tecytal.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Hi, I'm still doing experiment with CEL and recently I've noticed
that if:<br>
<br>
1- call enter in the pbx<br>
2- call enter a queue<br>
3- call get answered<br>
4- the operators call directly another queue, using the queue
number<br>
5- the call get answered<br>
6- the call end<br>
<br>
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: <br>
<br>
<pre>'1812621', 'BRIDGE_UPDATE', '2013-06-18 12:11:31', 'ISS23071100', '23071100', '23071100', '24872939', '', '21', 'from-internal', 'Local/1006@from-queue-00034a00;2', '', '', '', '', 'Queue', '21,tr,,', '3', '', '1371568269.486380', '1371568201.486360', 'Local/714126@from-queue-00034a04;1', '', '', ''</pre>
<br>
here you can se the extension called (21), the source channel
(Local/1006@from-queue-00034a00), the peer
(Local/714126@from-queue-00034a04) and especially you can see that
the app name is "queue". <br>
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.<br>
This is if I follow the call with linkedid 1371568201.486360.<br>
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.<br>
<br>
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?<br>
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?<br>
<br>
If someone can have a look I've attached the CSV for the two
linkedids..<br>
<br></div></blockquote><div><br></div><div style>Nope, this is entirely expected.</div><div style><br></div><div style>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@from-queue-00034a04;1 has replaced the channel Local/1006@from-queue-00034a00;2 was bridged with, SIP/1006-00007705. You can see that SIP/1006-00007705 is disposed of immediately following this event.</div>
<div style><br></div><div style>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@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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div> </div></div><div style>Matt</div><div style><br></div>-- <br><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Engineering Manager</div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div><div>
Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div></div>
</div></div>