Skip to main content

chan_local needs to die in huntlists.

Posted by eeman on Fri, 02/13/2009

I just had a customer call in to have some extensions removed from their account. After speaking with the helpdesk they removed 3 of their extensions. However, those extensions were members of a huntlist. The customer assumed everything was OK, because when they went into the huntlist menu it did not list the, now deleted, extensions. This resulted in their ring group getting hijacked and all calls to the company were presented with 'that extension is invalid' message.

why? Currently extensions are passed through a macro that dynamically builds a dial string that looks like this....

Dial(Local/100@from-inside-tenant&Local/101@from-inside-tenant&Local102@from-inside-tenant,20,)

Because the Dial application is using chan_local to traverse the dialplan, the call is getting answered by other applications. Since Dial passes the call through to the first answered technology, Playback(invalid) now hijacks all the calls.

This does not happen when you construct a ring group such as

Dial(SIP/100&SIP/101&SIP/101,20,i)

if SIP/102 doesnt actually exist it errors but continues ringing SIP/100 and SIP/101

As long as Dial is sent to dialplan instead of a direct technology (using chan_local) then other, unintended elements are going to create an ANSWERED state with dire consequenses.