[asterisk-users] PBX -> PRI -> * -> Telco not working

[Mikel Lindsaar]

On Sat, Nov 15, 2008 at 11:05 PM, Tony Mountifield <tony at softins.clara.co.uk
> wrote:

> In article <57a815bf0811142025k57b2773cq3eb5f1c9c2913783 at mail.gmail.com>,
> Mikel Lindsaar <raasdnil at gmail.com> wrote:
> > I have an NEC PBX connected via a TE210p E1 line to an asterisk 1.6 box.
> > NEC -> E1 -> TE210P:1 -> * -> TE210P:2 -> E1 -> Telco
> > Incomming calls from the telco to the asterisk box to the NEC work fine
> with
> > indials and everything.  Works sweet.
> > Outbound from the NEC to the Asterisk box fail.  Giving an long dial tone
> > that then times out.
>
> You need to understand how the NEC interacted with the Telco before the
> Asterisk box was inserted.
> You might want to try changing immediate=no to immediate=yes on span 1.
> If that's the case, you might need a different dialplan too:
> If that doesn't work, you could try doing this at the Asterisk
> CLI> prompt:


Yup, didn't work.  Ended up timing out on the WaitExten command and looking
for the t exten, which means it didn't receive a number to dial...

Here is the verbose output:

    -- Accepting call from '' to 's' on channel 0/31, span 1
    -- Executing [s at from-nec:1] WaitExten("DAHDI/31-1", "") in new stack
[Nov 16 14:10:01] WARNING[7729]: pbx.c:7787 pbx_builtin_waitexten: Timeout
but no rule 't' in context 'from-nec'
  == Spawn extension (from-nec, s, 1) exited non-zero on 'DAHDI/31-1'
    -- Hungup 'DAHDI/31-1'

Because this didn't work, I changed it back to immediate = no.

And removed the WaitExten from the from-nec context.

Now I don't get the constant dial tone any more, I get an immediate busy
with asterisk reporting:

    -- Extension 's' in context 'from-nec' from '' does not exist.
 Rejecting call on channel 0/31, span 1

Which means it's not getting the number to dial somehow.


> Then post the contents of /tmp/pri.txt if it's not too huge, or else
> put it up on a file server or web site and post the URL.
>

Isn't too long.  There are no other calls happening at the moment, so is
nice and short:

< Protocol Discriminator: Q.931 (8)  len=19
< Call Ref: len= 2 (reference 1/0x1) (Originator)
< Message type: SETUP (5)
< [04 03 80 90 a3]
< Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer
capability: Speech (0)
<                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode
(16)
<                                User information layer 1: A-Law (35)
< [18 03 a1 83 9f]
< Channel ID (len= 5) [ Ext: 1  IntID: Implicit  PRI  Spare: 0  Preferred
 Dchan: 0
<                        ChanSel: As indicated in following octets
<                       Ext: 1  Coding: 0  Number Specified  Channel Type: 3
<                       Ext: 1  Channel: 31 ]
< [6c 02 21 81]
< Calling Number (len= 4) [ Ext: 0  TON: National Number (2)  NPI:
ISDN/Telephony Numbering Plan (E.164/E.163) (1)
<                           Presentation: Presentation permitted, user
number passed network screening (1)  '' ]
-- Making new call for cr 1
-- Processing Q.931 Call Setup
-- Processing IE 4 (cs0, Bearer Capability)
-- Processing IE 24 (cs0, Channel Identification)
-- Processing IE 108 (cs0, Calling Party Number)
q931.c:3509 q931_receive: call 1 on channel 31 enters state 6 (Call Present)
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Call Present, peerstate Call
Initiated
q931.c:3104 q931_release_complete: call 1 on channel 31 enters state 0
(Null)
> Protocol Discriminator: Q.931 (8)  len=9
> Call Ref: len= 2 (reference 1/0x1) (Terminator)
> Message type: RELEASE COMPLETE (90)
> [08 02 81 81]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0
 Location: Private network serving the local user (1)
>                  Ext: 1  Cause: Unallocated (unassigned) number (1), class
= Normal Event (0) ]
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null


Any ideas?

Mikel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20081116/f3cb3cd7/attachment.htm