[Asterisk-Users] PRI: This number has been disconnected

Joe Pukepail pukepail at gmail.com
Thu Dec 29 11:21:44 MST 2005


I have tried both inband and outofband, doesn't seem to make a difference.
I added the congension and playtones(congestion) to the dial plan after the
dial, but the users just get a busy instead of "Do-De-Dah The number of have
reached is not in service <fastbusy>". PRI Debug below.



    -- Executing Dial("IAX2/sycam-16385", "Zap/g2/8157872800") in new stack
-- Making new call for cr 32816
    -- Requested transfer capability: 0x00 - SPEECH
> Protocol Discriminator: Q.931 (8)  len=46
> Call Ref: len= 2 (reference 48/0x30) (Originator)
> Message type: SETUP (5)
> [04 03 80 90 a2]
> Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer
capability: Speech (0)
>                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode
(16)
>                              Ext: 1  User information layer 1: u-Law (34)
> [18 03 a9 83 81]
> Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0, Exclusive
Dchan: 0
>                        ChanSel: Reserved
>                       Ext: 1  Coding: 0   Number Specified   Channel Type:
3
>                       Ext: 1  Channel: 1 ]
> [1e 02 80 83]I>
> Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0:
0   Location: User (0)
>                               Ext: 1  Progress Description: Calling
equipment is non-ISDN. (3) ]
> [6c 0c 41 80 38 31 35 37 35 34 38 38 32 33]
> Calling Number (len=14) [ Ext: 0  TON: Subscriber Number (4)  NPI:
ISDN/Telephony Numbering Plan (E.164/E.163) (1)
>                           Presentation: Presentation permitted, user
number not screened (0) '8157548823' ]
> [70 0b a1 38 31 35 37 38 37 32 38 30 30]
> Called Number (len=13) [ Ext: 1  TON: National Number (2)  NPI:
ISDN/Telephony Numbering Plan (E.164/E.163) (1) '8157872800' ]
    -- Called g2/8157872800
< Protocol Discriminator: Q.931 (8)  len=10
< Call Ref: len= 2 (reference 48/0x30) (Terminator)
< Message type: CALL PROCEEDING (2)
< [18 03 a9 83 81]
< Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0, Exclusive
Dchan: 0
<                        ChanSel: Reserved
<                       Ext: 1  Coding: 0   Number Specified   Channel Type:
3
<                       Ext: 1  Channel: 1 ]
-- Processing IE 24 (cs0, Channel Identification)
    -- Zap/25-1 is proceeding passing it to IAX2/sycam-16385
< Protocol Discriminator: Q.931 (8)  len=9
< Call Ref: len= 2 (reference 48/0x30) (Terminator)
< Message type: DISCONNECT (69)
< [08 02 82 81]
< Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location:
Public network serving the local user (2)
<                  Ext: 1  Cause: Unallocated (unassigned) number (1), class
= Normal Event (0) ]
-- Processing IE 8 (cs0, Cause)
    -- Channel 0/1, span 2 got hangup request
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Disconnect Indication,
peerstate Disconnect Request
> Protocol Discriminator: Q.931 (8)  len=18
> Call Ref: len= 2 (reference 48/0x30) (Originator)
> Message type: RELEASE (77)
> [08 02 81 81]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location:
Private network serving the local user (1)
>                  Ext: 1  Cause: Unallocated (unassigned) number (1), class
= Normal Event (0) ]
> [7e 07 04 58 0b 2d 08 31 35]
> User-User Information (len= 9) [ 04 58 0b 2d 08 31 35 ]
    -- Hungup 'Zap/25-1'
  == No one is available to answer at this time (1:0/0/0)
    -- Executing PlayTones("IAX2/sycam-16385", "congestion") in new stack
    -- Executing Congestion("IAX2/sycam-16385", "") in new stack
  == Spawn extension (pri, 7872800, 8) exited non-zero on 'IAX2/sycam-16385'
    -- Hungup 'IAX2/sycam-16385'
< Protocol Discriminator: Q.931 (8)  len=5
< Call Ref: len= 2 (reference 48/0x30) (Terminator)
< Message type: RELEASE COMPLETE (90)
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null





On 12/29/05, Adam Goryachev <mailinglists at websitemanagers.com.au> wrote:
>
> On Wed, 2005-12-28 at 14:00 -0300, Javier Ergas wrote:
> > I believe this behavior has nothing to do with the A at H Scripts. I think
> the
> > problem is in the PRI signalization.
> > I can see the zap hangup messages when trying to call a disconnected
> number.
> >       .....
> >     -- Executing Dial("SIP/9349-1787", "ZAP/g0/2514990") in new stack
> >     -- Called g0/2514990
> >     -- Channel 0/2, span 1 got hangup
> >     -- Hungup 'Zap/2-1'
> >   == No one is available to answer at this time
> >     -- Executing Goto("SIP/9349-1787", "s-NOANSWER|1") in new stack
> >     -- Goto (macro-dialout-trunk,s-NOANSWER,1)
> >       ....
> > The telco says they are sending inband information with the status of
> the
> > call, but Asterisk is hanging up the channel instead of connecting it to
> let
> > hear the audio message.
> >
> > There is a post with a similar issue here:
> > http://mailgate.supereva.com/comp/comp.dcom.isdn.capi/msg04138.html
> >
> > Is anyone experiencing the same behavior?
> >
>
> Sounds like the difference between doing inband signalling or out of
> band signalling. I think by default, a PRI uses out of band signalling,
> ie, it just sends a message saying "this number if un reachable" so
> asterisk just hangs up and plays the local congestion dialplan.
>
> What you need to do is use inband signalling, so that asterisk won't
> hangup, and instead will pass the audio from the telco through.
>
> See /etc/asterisk/zapata.conf:
> ; PRI Out of band indications.
> ; Enable this to report Busy and Congestion on a PRI using out-of-band
> ; notification. Inband indication, as used by Asterisk doesn't seem to
> work
> ; outofband:      Signal Busy/Congestion out of band with
> RELEASE/DISCONNECT
> ; inband:         Signal Busy/Congestion using in-band tones
> priindication = outofband
>
>
> Regards,
> Adam
>
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> Asterisk-Users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20051229/80272de7/attachment.htm


More information about the asterisk-users mailing list