Summary:ASTERISK-20318: Include channel uniqueid in "AsyncAGI" and "AGIExec" events
Reporter:Dan Cropp (daninmadison)Labels:
Date Opened:2012-08-24 10:37:46Date Closed:2012-09-28 17:17:27
Versions:10.3.1 10.7.0 Frequency of
Environment:Debian 64 bit, virtual machine, SIP.Attachments:( 0) res_agi_patch.txt
Description:We are using AMI and during load testing we occasionally see two calls with the same channelname.  
For the load test, we originate calls to ourselves.  Basically a loop back.  We go through a few thousand calls before encountering a case where the channel name matches another channel name.

We decided to use the UniqueId for identification purposes.  This works great for the calls.  However, since we are using AsyncAGI, we rely on the AsyncAGI related events to also have the UniqueId.
The channel's uniqueid is not included in the "AsyncAGI" and "AGIExec" events.
Comments:By: Michael L. Young (elguero) 2012-08-24 12:17:51.208-0500

Please attach your patch as a file.  If you have not done so yet, you need to sign a license agreement before submitting your patch.


By: Dan Cropp (daninmadison) 2012-08-24 12:23:54.283-0500

This is a svn diff comparison attached as a text document.

By: Matt Jordan (mjordan) 2012-08-24 12:36:24.959-0500

So.  Getting two channels with the same name is wrong, and could potentially lead to all sorts of unpleasentness in other places of Asterisk.

Can you provide a script that reproduces the situation?  Even better would be a DEBUG log showing the channel creation of the two channels with the same name.

By: Dan Cropp (daninmadison) 2012-08-24 13:01:31.808-0500

Unfortunately, all our code has been changed for a few months to rely on the Uniqueid instead of the channel name.

What we did is originate 20 calls simultanteously.  These calls would come back to us, we would answer them.  Then we automated behaviors on the calls.

This was back in May and I don't remember if it was the originated call that had a duplicate channel name or if it was the incoming call that had the duplicate channel name.

One slight correction to my original note.

These are Local channels that we were using, not SIP.
Channel: Local/333@IS-0ccc;1

By: Richard Mudgett (rmudgett) 2012-08-24 15:03:01.924-0500

I can see why chan_local could conceivably get duplicate channel names:

int randnum = ast_random() & 0xffff, fmt = 0;


if (!(tmp = ast_channel_alloc(1, state, 0, 0, t, p->exten, p->context, linkedid, ama, "Local/%s@%s-%04x;1", p->exten, p->context, randnum))
|| !(tmp2 = ast_channel_alloc(1, AST_STATE_RING, 0, 0, t, p->exten, p->context, tmp->linkedid, ama, "Local/%s@%s-%04x;2", p->exten, p->context, randnum))) {

The random number generator can return the same number for different channels.

A similar problem happened with chan_sip before a sequence number was used.  The chan_sip channel names used to use the pointer address of the private structure in its channel name, but on 64 bit systems only the lower 32 bits got used.

By: Matt Jordan (mjordan) 2012-08-27 07:15:26.100-0500

Your patch cannot be attached to the issue without signing the license contributor agreement.  Please sign the license contributor agreement and re-attach your patch.

By: Dan Cropp (daninmadison) 2012-08-27 09:33:31.633-0500

Attaching the patch after signing the License Agreement.

By: Jonathan Rose (jrose) 2012-09-11 17:11:03.467-0500

Ok, so here's the thing... we aren't going to change the agi code to deal with this problem. We couldn't do it in Asterisk 10 without introducing major breaking changes, and we'd prefer to leave it the same in new versions as well as long as we can fix the problem without changing it since that is the way we traditionally operate.

From the sound of things, this will probably incur something of a task for you since you'll either have to maintain this patch for your own machine or else you'll have to rework your scripts to use the channel names again. I'm sorry about that.

I have fixed the local channel naming issue though and am currently committing the patch to all versions between 1.8 and trunk.

By: Jonathan Rose (jrose) 2012-09-11 17:17:03.604-0500

EDIT:  Nevermind, it looks like the patch you wrote might still be introduced in trunk. It won't be going into 10 or 11 though. So as long as you don't mind it not being around until Asterisk 12, things should be alright on your end.