[asterisk-users] Acceptance testing of a new PRI

[Jay R. Ashworth]

On Sat, Jul 26, 2008 at 09:34:29PM +0300, Tzafrir Cohen wrote:
> On Sat, Jul 26, 2008 at 01:12:42PM -0400, Jay R. Ashworth wrote:
> > On Fri, Jul 25, 2008 at 10:57:49PM +0300, Tzafrir Cohen wrote:
> > > On Fri, Jul 25, 2008 at 01:54:21PM -0400, Jay R. Ashworth wrote:
> > > > On Thu, Jul 24, 2008 at 04:35:33PM +0300, Tzafrir Cohen wrote:
> > > > > What's wrong with plain old Zap/NN ?
> > > > > 
> > > > > [test]
> > > > > exten => _6XXX.,1,Dial(Zap/{EXTEN:1:3}/${EXTEN:4})
> > > > > 
> > > > > Now call 6<chan_num><number-to-dial> in context test.
> > > > 
> > > > As it happens, Asterisk 1.2 apparently will not recognize 'Zap/01-1' as
> > > > the argument to Dial, I get CHANUNAVAIL.
> > > 
> > > Zap/01-1 ??? How come?
> > > 
> > > Zap/01 is valid and equivalent to Zap/1 .
> > 
> > And yet, feeding it to Dial didn't work, and stripping the 0 off did.
> > 
> > I'm on 1.2 if that makes a diff.
> 
> I've used this extensively since 1.0, FWIW.
> 
> Looking at the code: the paarsing is done by sscanf. Maybe it does not
> consider a number with a leading 0 as a number?
> 
> What error/warning do you get when trying to use Zap/01 ?

Chanunavail/Congestion.

Here, let me go get the exact message...

==============8<========================8<============================
    -- Executing AGI("SIP/101cathy-b7619990", "call_log.agi|880116142154432")
in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/call_log.agi
+++++ CALL LOG START : |1216995262.36|SIP/101cathy-b7619990|880116142154432|SIP|
7274514974|2008-07-25 10:14:22
    -- AGI Script call_log.agi completed, returning 0
    -- Executing Dial("SIP/101cathy-b7619990", "Zap/01-1/16142154432|30|o") in
 new stack
Jul 25 10:14:22 NOTICE[25497]: app_dial.c:1076 dial_exec_full: Unable to create
channel of type 'Zap' (cause 0 - Unknown)
  == Everyone is busy/congested at this time (1:0/0/1)
    -- Executing NoOp("SIP/101cathy-b7619990", "CHANUNAVAIL") in new stack
    -- Executing NoOp("SIP/101cathy-b7619990", "Hangup Cause: 0") in new stack
    -- Executing Hangup("SIP/101cathy-b7619990", "") in new stack
  == Spawn extension (default, 880116142154432, 5) exited non-zero on 'SIP/101
cathy-b7619990'
==============8<========================8<============================

Copied and pasted.  I later extended the rules, as you saw, to have a
special rule for 880X, and it worked just fine.

Not sure what to tell you, but it seems to be that.

Note that I have not *yet* taken the "-1" off the end, so it cannot be
that.

Cheers,
-- jra
-- 
Jay R. Ashworth                   Baylink                      jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com                     '87 e24
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274

	     Those who cast the vote decide nothing.
	     Those who count the vote decide everything.
	       -- (Josef Stalin)