Uniqueid's on channels are current not copied with the rest of the channel to it's new struct ast_channel home during a channel masquerade. I would like to request that be changed, maybe with an option to restore the old behavor for backward compatability.<br>
<br>A little over a year ago I asked about how channel uniqueid's aren't copied over during a channel masquerade: <a href="http://lists.digium.com/pipermail/asterisk-dev/2009-May/038430.html">http://lists.digium.com/pipermail/asterisk-dev/2009-May/038430.html</a> and I was told that was intentional. IMHO the arguments weren't that strong and could be worked around.<br>
<br>One place this change would benefit is CEL. (I finally got around to playing with CEL in trunk.).<br>The CEL events for a sip attended transfer go something like this (I'm just giving the part after the dot for the uniqueid for brevity):<br>
First there's CHAN_START events for uniqueid's .8 and .9, then there's a BRIDGE_START with .8 (might be nice if the event mentioned the other end).<br>Then there's CHAN_START events for .10 and .11, and a BRIDGE_START for .10<br>
Then there's an ATTENDEDTRANSFER event for .10 and a BRIDGE_UPDATE for 10.<br>Next there's an BRIDGE_END for .8, and a HANGUP for .9 followed by a CHAN_END for .9., then there's HANGUP and CHAN_END for .8.<br>
Then there's a time gap while the two remaining channels talk, and then BRIDGE_END .10 and HANGUP and CHAN_END's for .10 and .11.<br><br>The problem with that is the channels that were actually talking to each other at the end were the ones that came in as .9 and .11.<br>
If I'm logging CEL events to the database, there is no way to ask the database for all events for .9, because it's uniqueid actually changed to .10 during the ATTENDEDTRANSFER event, because it's guts were ripped out of .9 and put into .10. <br>
<br>There's the linkedid field, but isn't useful if I want to look at just one leg. And it ends up changing on .11 from .10 to .8 after the transfer, which means there's no single linkedid I could query for to get all the events for all the related channels for that call.<br>
<br>If I was trying to bill using this information, I would think that .9 hung up long before it really did and under charge that leg.<br><br>To complicate matters, the CDR *IS* copied during the channel masquerade. And the CDR contains its own copy of the uniqueid. So after the attended transfer, UNIQUEID != CDR(UNIQUEID). A 'core show channel' after the SIP attended transfer can confirm this. I'm guessing this part of the current behavor is a bug?<br>
<br>One thing this change would screw up is the queue_log. Right now, if someone does a sip attended transfer into a queue, all the queue events end up with the same uniqueid (the channel changes during the middle, but so does the uniqueid, so it works out). To solve that, we would have to add an app_queue instance id to the log. That would actually be useful anyway. Right now, if the same channel goes through more than one queue, or the same queue more than once, it's really hard to join those events togehter in the database.<br>