[asterisk-users] UNIQUEID not the same in Dialplan as passedtoAGI

Wed Sep 9 09:12:44 CDT 2009

Hi Danny,

Thanks again for your help. I figured out how to do this... It was
through my own retardedness that I had messed it up.

In the application map section of features.conf, I just swapped self for peer...
used to be:
tag1 => *1,self,AGI,tag1.agi

is now:
tag1 => *1,peer,AGI,tag1.agi

That selects which channel is active for the call. I should have
realized this earlier.

Thanks again for your help.
Örn

2009/9/9 Örn Arnarson <orn at arnarson.net>:
> Hi Danny,
>
> Thanks. Yes, that's where I'm getting the UNIQUEID. The problem is
> that it is not for the same leg as the UNIQUEID in the Dialplan. If I
> were able to get the same UNIQUEID somehow in both places, my problems
> would be solved :-)
>
> Regards,
> Örn
>
> On Wed, Sep 9, 2009 at 2:00 PM, Danny Nicholas<danny at debsinc.com> wrote:
>> Per this link - http://www.voip-info.org/wiki/view/Asterisk+AGI you should
>> have a variable agi_uniqueid with the uniqueid of the leg available in the
>> AGI.
>>
>> -----Original Message-----
>> From: asterisk-users-bounces at lists.digium.com
>> [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Örn Arnarson
>> Sent: Wednesday, September 09, 2009 8:52 AM
>> To: Asterisk Users Mailing List - Non-Commercial Discussion
>> Subject: Re: [asterisk-users] UNIQUEID not the same in Dialplan as
>> passedtoAGI
>>
>> If only features.conf accepted the normal syntax of running
>> applications... As I understand it (and tested it), it must accept the
>> application in the syntax name => keycode,WHO,application,parameters
>>
>> Goto would work, but then it will only be able to use Goto,priority
>>
>> On Wed, Sep 9, 2009 at 1:41 PM, Danny Nicholas<danny at debsinc.com> wrote:
>>> Actually (and this is probably an incorrect or misquoted statement), any
>>> action from features is a fork.  If you change tag1 from
>>> - tag1 => *1,self,AGI,tag1.agi
>>> To
>>> - tag1 => *1,self,Goto(runagi|s|1)
>>>
>>> The feature will jump to a context in your dialplan instead of directly
>>> executing the AGI command.
>>>
>>> This may or may not work, but it should IMO.
>>>
>>> -----Original Message-----
>>> From: asterisk-users-bounces at lists.digium.com
>>> [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Örn Arnarson
>>> Sent: Wednesday, September 09, 2009 8:34 AM
>>> To: Asterisk Users Mailing List - Non-Commercial Discussion
>>> Subject: Re: [asterisk-users] UNIQUEID not the same in Dialplan as passed
>>> toAGI
>>>
>>> Thanks for your reply.
>>>
>>> One thing I forgot to mention is that the AGI is called via
>>> features.conf -- in a call, if you press, e.g. *1, you tag the call as
>>> calltype 1.
>>> As I cannot (as far as I know) call the AGI from features.conf with
>>> parameters (such as ${UNIQUEID}), I need to get those parameters from
>>> STDIN.
>>>
>>> This is an example from features.conf:
>>> tag1 => *1,self,AGI,tag1.agi
>>>
>>> So, *1 in the active call calls this AGI. You might be right -- it's
>>> just treated as another call (even though there is no fork, hangup or
>>> transfer involved), but if this is the case, does anyone have an idea
>>> how to pass parameters to tag1.agi via features.conf?
>>>
>>> Best regards,
>>> Örn
>>>
>>> On Wed, Sep 9, 2009 at 1:14 PM, Danny Nicholas<danny at debsinc.com> wrote:
>>>> To quote Steve Edwards from an earlier post this month "The UniqueID
>>>> consists of the origination time plus the number of calls for this
>>> instance
>>>> of the Asterisk execution".  Looking at the log you posted, these are two
>>>> separate (as far as Asterisk is concerned) calls.  If you look in your
>>> CDR,
>>>> you should see an entry for each.  If you want to track a call via an
>> AGI,
>>>> you should do this:
>>>> - exten => s,1,set(thisuid=${UNIQUEID})
>>>> - exten => s,2,AGI(youragi.agi|${thisuid})
>>>>
>>>> Just a guess, but UNIQUEID is probably reassigned on these events;
>>>> Hangup
>>>> Fork
>>>> Transfer
>>>> (go ahead guys, correct away - like I said, it's just a guess).
>>>>
>>>> -----Original Message-----
>>>> From: asterisk-users-bounces at lists.digium.com
>>>> [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Örn
>> Arnarson
>>>> Sent: Wednesday, September 09, 2009 7:56 AM
>>>> To: Asterisk Users Mailing List - Non-Commercial Discussion
>>>> Subject: [asterisk-users] UNIQUEID not the same in Dialplan as passed to
>>> AGI
>>>>
>>>> Hi,
>>>>
>>>> I've noticed that the UNIQUEID for a call is not the same in the
>>>> Dialplan (when executed e.g. exten => s,n,NoOp(${UNIQUEID}) as it is
>>>> when passed via STDIN to an AGI script.
>>>> Is this normal, and is this supposed to behave this way?
>>>>
>>>> The UNIQUEID received in the AGI is usually .001 higher than the one
>>>> in the dial plan -- but sometimes it is also a second behind.
>>>> Here's an example from the dialplan, with the corresponding argument
>>>> passed to the AGI:
>>>>
>>>>    -- Executing [s at macro-internal-call:7]
>>>> NoOp("SIP/10.0.0.4-082a0658", "1252500374.334") in new stack
>>>>
>>>> agi_uniqueid: 1252500374.335
>>>>
>>>> And here's an example where the UNIQUEID is one second and one
>>>> fraction point behind:
>>>>
>>>>    -- Executing [s at macro-internal-call:7]
>>>> NoOp("SIP/10.0.0.4-0825ef60", "1252500762.337") in new stack
>>>>
>>>> agi_uniqueid: 1252500763.338
>>>>
>>>> Any advice would be greatly appreciated. Can I use something else as a
>>>> unique identifier for a call? I'm trying to tag calls, but it is
>>>> proving difficult with the ever-changing UNIQUEID.
>>>>
>>>> I haven't found a rule as to when it is delayed by a second and when it
>>>> isn't.
>>>>
>>>> Best regards,
>>>> Örn
>>>>
>>>> _______________________________________________
>>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>>
>>>> AstriCon 2009 - October 13 - 15 Phoenix, Arizona
>>>> Register Now: http://www.astricon.net
>>>>
>>>> asterisk-users mailing list
>>>> To UNSUBSCRIBE or update options visit:
>>>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>>>>
>>>>
>>>> _______________________________________________
>>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>>
>>>> AstriCon 2009 - October 13 - 15 Phoenix, Arizona
>>>> Register Now: http://www.astricon.net
>>>>
>>>> asterisk-users mailing list
>>>> To UNSUBSCRIBE or update options visit:
>>>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>>>>
>>>
>>> _______________________________________________
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>
>>> AstriCon 2009 - October 13 - 15 Phoenix, Arizona
>>> Register Now: http://www.astricon.net
>>>
>>> asterisk-users mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>>>
>>>
>>> _______________________________________________
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>
>>> AstriCon 2009 - October 13 - 15 Phoenix, Arizona
>>> Register Now: http://www.astricon.net
>>>
>>> asterisk-users mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>>>
>>
>> _______________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> AstriCon 2009 - October 13 - 15 Phoenix, Arizona
>> Register Now: http://www.astricon.net
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>>
>>
>> _______________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> AstriCon 2009 - October 13 - 15 Phoenix, Arizona
>> Register Now: http://www.astricon.net
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>>
>