[asterisk-users] Dealing with progress codes

[arkda]

Hi,

I've ran into an issue with a PRI provider in a major metropolitan area that
I haven't needed to deal with before and I was hoping someone might have
some insight on how to handle this within the Asterisk dialplan.

At this location users can't always tell if a number is long distance or not
(there are a lot of area codes and prefixes in the vicinity). Additionally,
users are required by the provider to dial the full 10 digit number even if
a call is local since a local call could be for a few different area codes
and prefixes. The problem is the provider requires a 1 in front of the
number for long distance calls, but errors out if the call has a 1 in front
and the call is local.

As a result, users are complaining that they are constantly having to redial
with or without the 1. I've tracked down this behavior when a call fails:

    -- Executing [5551515121 at internal:1] Set("SIP/user9-b696fb58",
"GROUP(default)=dialpool") in new stack
    -- Executing [5551515121 at internal:2] GotoIf("SIP/user9-b696fb58", "1?5")
in new stack
    -- Goto (internal,5551515121,5)
    -- Executing [5551515121 at internal:5] Set("SIP/user9-b696fb58",
"GROUP(default)=dialpool") in new stack
    -- Executing [5551515121 at internal:6] Answer("SIP/user9-b696fb58", "") in
new stack
    -- Executing [5551515121 at internal:7] Set("SIP/user9-b696fb58",
"CALLERID(num)=5552223333") in new stack
    -- Executing [5551515121 at internal:8] Set("SIP/user9-b696fb58",
"CALLERID(name)=HiThere") in new stack
    -- Executing [5551515121 at internal:9] NoOp("SIP/user9-b696fb58", "--out
the pri--") in new stack
    -- Executing [5551515121 at internal:10] Dial("SIP/user9-b696fb58",
"Zap/G2/15551515121") in new stack
    -- Requested transfer capability: 0x00 - SPEECH
    -- Called G2/15551515121
    -- Zap/22-1 is proceeding passing it to SIP/user9-b696fb58
    -- PROGRESS with cause code 31 received
    -- Zap/22-1 is making progress passing it to SIP/user9-b696fb58
    -- Hungup 'Zap/22-1'
  == Spawn extension (internal, 5551515121, 10) exited non-zero on
'SIP/user9-b696fb58'

The above call was a call that is considered local by the provider. The
caller is then redirected to a message (by the provider) saying 'You do not
need to dial a one or zero...' and the message repeats indefinitely.

I'd like to figure out how to handle this in the dial plan so users do not
even know anything happened. To test to see if I could stop the call
progress and reroute it I've tried this so far:

exten => _NXXXXXXXXX,1,Set(GROUP(default)=dialpool)
exten => _NXXXXXXXXX,2,GotoIf($[${GROUP_COUNT(priout at default)}<19]?5)
exten => _NXXXXXXXXX,3,GotoIf($[${GROUP_COUNT(congest at default)}>18]?BLOCK)
exten => _NXXXXXXXXX,4,NoOp
exten => _NXXXXXXXXX,5,Set(GROUP(default)=dialpool)
exten => _NXXXXXXXXX,6,Answer()
exten => _NXXXXXXXXX,7,Set(CALLERID(num)=${CLR})
exten => _NXXXXXXXXX,8,Set(CALLERID(name)=HiThere)
exten => _NXXXXXXXXX,9,NoOp(--out the pri--)
; Primary Dialout
exten => _NXXXXXXXXX,10,Dial(Zap/G2/1${EXTEN})
exten => _NXXXXXXXXX,11,GotoIf,($[${HANGUPCAUSE} = 31]?YAY)
exten => _NXXXXXXXXX,12,Hangup()
; Call limiter
exten => _NXXXXXXXXX,n(BLOCK),Answer()
exten => _NXXXXXXXXX,n(BLOCK),Playback(all-circuits-busy-now)
exten => _NXXXXXXXXX,n(BLOCK),Playback(pls-try-call-later)
exten => _NXXXXXXXXX,n(BLOCK),Hangup()
; 1 tester
exten => _NXXXXXXXXX,n(YAY),Answer()
exten => _NXXXXXXXXX,n(YAY),Playback(beep)
exten => _NXXXXXXXXX,n(YAY),Hangup()

It doesn't work. The user simply hangs up when the message is heard and the
next line in the dialplan isn't followed. How can I detect that a call has
received a progress code 31 then reroute it to another extension? From what
I found on voip-info.org (
http://www.voip-info.org/wiki/index.php?page=Asterisk+variable+hangupcause )
this should work. What am I missing?

The server is running Asterisk 1.4.21.1, zaptel 1.4.11, libpri 1.4.5,
compiled from source.

Thanks in advance!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20081028/3d324dc4/attachment.htm