asterisk users - Oct 2010 - AMI getting related channels in Ringing state

Issuing the AMI Status command results in a list of active channels. But
how to figure out which channels are related before the call is
answered? 2 channels below are somehow associated, but how can I be 100%
sure they are related in order to implement a redirect of the incoming
call to another phone ("attended" call pickup respecting
call/pickupgroups).

Uniqueid seems to be a timestamp, an IVR menu will render it useless for
this purpose. Same with the "random" part of the SIP channels
(0000177f/00001780), this will not be sequential when multiple calls
occur with IVRs.

'SIP/922-00001780' => array 
(
   'Privilege' => 'Call',
   'Channel' => 'SIP/922-00001780',
   'CallerIDNum' => '922',
   'CallerIDName' => '<unknown>',
   'Account' => '',
   'State' => 'Ringing',
   'Uniqueid' => '1286364290.8475',
)
'SIP/trunk-0000177f' => array 
(
   'Privilege' => 'Call',
   'Channel' => 'SIP/trunk-0000177f',
   'CallerIDNum' => 'trunk',
   'CallerIDName' => '0031234567890',
   'Accountcode' => '',
   'ChannelState' => '4',
   'ChannelStateDesc' => 'Ring',
   'Context' => 'macro-dial-one',
   'Extension' => 's',
   'Priority' => '37',
   'Seconds' => '3',
   'Uniqueid' => '1286364290.8474',
)

-- 

   Daniel Tryba

On Wed, Oct 06, 2010 at 01:56:55PM +0200, Daniel Tryba
wrote:
> Issuing the AMI Status command results in a list of active channels. But
> how to figure out which channels are related before the call is
> answered?
CoreShowChannels gives a little bit of extra data in the originator
channel:

Application: Dial
ApplicationData: SIP/922

This makes finding the actual ringing SIP device fun when the incoming
channel dials a Local/999 at default device. And doesn't give any usefull
hint when the incoming channel doesn't use Dial but e.g. Queue.

-- 

   Daniel Tryba

On Wed, Oct 06, 2010 at 01:56:55PM +0200, Daniel Tryba
wrote:
> Issuing the AMI Status command results in a list of active channels. But
> how to figure out which channels are related before the call is
> answered? 
Anybody?

My workaround for this problem is setting a persistent variable in the 
incoming channel:
Set(__xuniqueid=${RAND(100000,999999)}-${CALLERID(num)}-${EXTEN})
and match related channels this on the same xuniqueid variable.
To bad * doesn't set such a variable itself, I now have to make sure any
originating call executes this function.

-- 

   Daniel Tryba