[asterisk-dev] uniqueids and channel masquerades

[Tim Ringenbach]

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.

A little over a year ago I asked about how channel uniqueid's aren't copied
over during a channel masquerade:
http://lists.digium.com/pipermail/asterisk-dev/2009-May/038430.html and I
was told that was intentional. IMHO the arguments weren't that strong and
could be worked around.

One place this change would benefit is CEL. (I finally got around to playing
with CEL in trunk.).
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):
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).
Then there's CHAN_START events for .10 and .11, and a BRIDGE_START for .10
Then there's an ATTENDEDTRANSFER event for .10 and a BRIDGE_UPDATE for 10.
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.
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.

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.
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.

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.

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.

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?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20100624/51a56008/attachment-0001.htm