Correct Way to Add Dynamic Agents?

I’m trying to use PHP to add dynamic agents to our queues via the manager interface. Previously, I was doing the following:

Action: QueueAdd
Queue: 301
Interface: SIP/358
Penalty: 1
Paused: false

However, we were having the problem described in this ticket http://www.freepbx.org/trac/ticket/2696 so I changed the script to:

Action: QueueAdd
Queue: 301
Interface: Local/358@from-internal/n
Penalty: 1
Paused: false

With that change in place, the voicemail problem was resolved but a new one came up. Essentially, randomly, our agents would have a queue call that only rang once before going to the next agent in the queue. I looked in the logs and found this bit:

May 14 13:11:05 VERBOSE[26066] logger.c: -- AGI Script dialparties.agi completed, returning 0 May 14 13:11:05 DEBUG[26066] app_macro.c: Executed application: AGI May 14 13:11:05 VERBOSE[26066] logger.c: -- Executing Dial("Local/358@from-internal-7f21,2", "SIP/358|15|rwM(auto-blkvm)") in new stack May 14 13:11:05 DEBUG[26066] chan_sip.c: Setting NAT on RTP to 0 May 14 13:11:05 DEBUG[26066] chan_sip.c: Outgoing Call for 358 May 14 13:11:05 VERBOSE[26066] logger.c: -- Called 358 May 14 13:11:05 VERBOSE[25659] logger.c: -- Local/358@from-internal-7f21,1 is ringing May 14 13:11:05 DEBUG[3715] chan_sip.c: (Provisional) Stopping retransmission (but retaining packet) on '[email protected]' Request 102: Found May 14 13:11:05 DEBUG[3715] chan_sip.c: (Provisional) Stopping retransmission (but retaining packet) on '[email protected]' Request 102: Found May 14 13:11:05 DEBUG[3595] channel.c: Avoiding initial deadlock for 'SIP/358-090d2960' [b]May 14 13:11:05 VERBOSE[26066] logger.c: -- SIP/358-090d2960 is ringing May 14 13:11:05 VERBOSE[25659] logger.c: -- Nobody picked up in 15000 ms[/b] May 14 13:11:05 DEBUG[26066] chan_sip.c: update_call_counter(358) - decrement call limit counter May 14 13:11:05 DEBUG[26066] chan_sip.c: Acked pending invite 102 May 14 13:11:05 DEBUG[26066] chan_sip.c: Stopping retransmission on '[email protected]' of Request 102: Match Found May 14 13:11:05 DEBUG[26066] app_dial.c: Exiting with DIALSTATUS=CANCEL. May 14 13:11:05 VERBOSE[26066] logger.c: == Spawn extension (macro-dial, s, 7) exited non-zero on 'Local/358@from-internal-7f21,2' in macro 'dial' May 14 13:11:05 VERBOSE[26066] logger.c: == Spawn extension (macro-dial, s, 7) exited non-zero on 'Local/358@from-internal-7f21,2' in macro 'exten-vm' May 14 13:11:05 VERBOSE[26066] logger.c: == Spawn extension (macro-dial, s, 7) exited non-zero on 'Local/358@from-internal-7f21,2' May 14 13:11:05 VERBOSE[26066] logger.c: -- Executing Macro("Local/358@from-internal-7f21,2", "hangupcall") in new stack

Here’s the definition of the queue from queues_additional:

[301] announce-frequency=120 announce-holdtime=yes eventmemberstatus=no eventwhencalled=no joinempty=yes leavewhenempty=yes maxlen=0 monitor-format=wav monitor-join=yes music=CreativeCommons periodic-announce= periodic-announce-frequency=60 queue-callswaiting=queue-callswaiting queue-thankyou=queue-thankyou queue-thereare=queue-thereare queue-youarenext=queue-youarenext retry=5 strategy=rrmemory timeout=15 wrapuptime=0 agentannounce= context=

I’m not sure if I’m not adding agents correctly or if something else is wrong. We only started having this one ring problem after I changed from SIP to Local. Any guidance or links are appreciated in advance. I search with Google but couldn’t find anything directly related.

Edit: We’re using FreePBX 2.4.0.0 with Asterisk 1.2.24. Sorry for not including this before.

Not to self bump, but I was wondering if fresh eyes might have any insight into this? We’re getting ready to upgrade to Asterisk 1.4.x and it would be good to resolve this issue at the same time.

I had this problem when using rrmemory as the strategy. Using roundrobin I never see this. Thats on asterisk 1.4.21.2 with freepbx 2.4.1.1

Has anyone else seen this?

/justin

That’s interesting. We recently moved from that strategy to ringall. I’ll try it again and see if the problem goes away.

Tried it out today and with the ringall strategy, everything works as expected. Using Local/ instead of SIP/ does seem to add a lot of extra entries to the CDR table (Local/354 calls SIP/354 and it isn’t answered because that user didn’t answer the queue call) but I’m sure that’s probably “accurate”, just different.