On Sun, Jun 30, 2013 at 4:24 PM, Fabio Moretti <fmore...@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@from-queue-00034a00;2', '', '', '', '', 'Queue', '21,tr,,', '3', > '', '1371568269.486380', '1371568201.486360', > 'Local/714126@from-queue-00034a04;1', '', '', '' > > > 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". > 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@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. 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. 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
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
