thr3ads.net - asterisk users - [asterisk-users] PRI Gurus ONLY

If this information is useful, please help other people find it:
Share via:

bruce bruce

2010-Apr-12 19:22 UTC

[asterisk-users] PRI Gurus ONLY - Too complex of an issue

Hi Guys,

Full PRI installed in Canada with Sangoma A101DE and Asterisk 1.4.21.2,
LibPRI 1.4.10.

Placing a call into PRI and then transfering that call out to another
number. Problem is that the call rings out but the moment the other party
pickups both legs of the call are disconnected give Cause code 16.

*********************************************************************************************************************
Dialplan:
[zap_bridge]
exten => s,1,answer()
exten => s,n,Dial(ZAP/g0/4168889999)
*********************************************************************************************************************


********************************************************************************************************************
CLI Output:
    -- Called g0/4168889999
    -- Zap/2-1 is proceeding passing it to Zap/1-1
    -- Zap/2-1 is ringing
    -- Zap/2-1 answered Zap/1-1
    -- Native bridging Zap/1-1 and Zap/2-1
    -- Channel 0/1, span 1 got hangup request, cause 16
    -- Hungup 'Zap/2-1'
  == Spawn extension (zap_bridge, s, 2) exited non-zero on 'Zap/1-1'
    -- Hungup 'Zap/1-1'
*********************************************************************************************************************


*********************************************************************************************************************
Here is PRI debug:
Starting just before Channel two is connected until both channels are
disconnected *(maybe FACILITY 98 is of interest?!)*:

< Message type: CONNECT (7)
q931.c:3626 q931_receive: call 32865 on channel 2 enters state 10
(Active)> Protocol Discriminator: Q.931 (8)  len=5
> Call Ref: len= 2 (reference 97/0x61) (Originator)
> Message type: CONNECT ACKNOWLEDGE (15)    -- Zap/2-1 answered Zap/1-1
    -- Native bridging Zap/1-1 and Zap/2-1> Protocol Discriminator: Q.931 (8)  len=27
> Call Ref: len= 2 (reference 96/0x60) (Originator)
> Message type: FACILITY (98)
> [1c 14 91 a1 11 02 01 06 06 07 2a 86 48 ce 15 00 08 30 03 02 01 61]
> Facility (len=22, codeset=0) [ 0x91, 0xA1, 0x11, 0x02, 0x01, 0x06, 0x06,0x07, '*', 0x86, 'H', 0xCE, 0x15, 0x00, 0x08, '0', 0x03,
0x02, 0x01, 'a' ]
PROTOCOL 11
A1 0011 (CONTEXT SPECIFIC [1])
  02 0001 06 (INTEGER: 6)
  06 0007 2A 86 48 CE 15 00 08 (OBJECTIDENTIFIER: 2a 86 48 ce 15 00 08)
  30 0003 (SEQUENCE)
    02 0001 61 (INTEGER: 97)
< Protocol Discriminator: Q.931 (8)  len=9
< Call Ref: len= 2 (reference 96/0x60) (Terminator)
< Message type: DISCONNECT (69)
< [08 02 80 90]
< Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0
 Location: User (0)
<                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event
(1) ]
-- Processing IE 8 (cs0, Cause)
q931.c:3826 q931_receive: call 32864 on channel 1 enters state 12
(Disconnect Indication)
    -- Channel 0/1, span 1 got hangup request, cause 16
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Active, peerstate Connect
Request
q931.c:3015 q931_disconnect: call 32865 on channel 2 enters state 11
(Disconnect Request)> Protocol Discriminator: Q.931 (8)  len=9
> Call Ref: len= 2 (reference 97/0x61) (Originator)
> Message type: DISCONNECT (69)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0
 Location: Private network serving the local user (1)>                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event(1) ]
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Disconnect Indication,
peerstate Disconnect Request
q931.c:2967 q931_release: call 32864 on channel 1 enters state 19 (Release
Request)> Protocol Discriminator: Q.931 (8)  len=9
> Call Ref: len= 2 (reference 96/0x60) (Originator)
> Message type: RELEASE (77)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0
 Location: Private network serving the local user (1)>                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event(1) ]
    -- Hungup 'Zap/1-1'
< Protocol Discriminator: Q.931 (8)  len=5
< Call Ref: len= 2 (reference 96/0x60) (Terminator)
< Message type: RELEASE COMPLETE (90)
q931.c:3766 q931_receive: call 32864 on channel 1 enters state 0 (Null)
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null
< Protocol Discriminator: Q.931 (8)  len=5
< Call Ref: len= 2 (reference 97/0x61) (Terminator)
< Message type: RELEASE (77)
q931.c:3801 q931_receive: call 32865 on channel 2 enters state 0 (Null)
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Release
Request> Protocol Discriminator: Q.931 (8)  len=9
> Call Ref: len= 2 (reference 97/0x61) (Originator)
> Message type: RELEASE COMPLETE (90)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0
 Location: Private network serving the local user (1)>                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event(1) ]
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null
*********************************************************************************************************************

Any input and thought is appreciated on this. This is really annoying me as
there are no pointers as to why LibPRI is asking to disconnect once the
channel is connected.

Thanks,
Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20100412/c24711a7/attachment.htm

Tim Nelson

2010-Apr-12 20:02 UTC

head link

[asterisk-users] PRI Gurus ONLY - Too complex of an issue

----- "bruce bruce" <bruceb444 at gmail.com> wrote:
> Hi Guys, 
> 
>Full PRI installed in Canada with Sangoma A101DE and Asterisk 1.4.21.2,
LibPRI 1.4.10.
> 
> ...etc 
I was going to respond with some very insightful and helpful information but
I'm not a "PRI Guru". Sorry, maybe next time.

--Tim 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20100412/dc1c1f9e/attachment.htm

Don Kelly

2010-Apr-12 20:14 UTC

head link

[asterisk-users] PRI Gurus ONLY - Too complex of an issue

It is normal for the PSTN switch to disconnect both channels when a Two
B-Channel Transfer is completed successfully.

 

Are the two parties connected?

--Don

Don Kelly

PCF Corp
People Come First
651 842-1000
888 Don Kell(y)
651 842-1001 fax

  _____  

From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of bruce bruce
Sent: Monday, April 12, 2010 2:22 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: [asterisk-users] PRI Gurus ONLY - Too complex of an issue

 

Hi Guys,

 

Full PRI installed in Canada with Sangoma A101DE and Asterisk 1.4.21.2,
LibPRI 1.4.10.

 

Placing a call into PRI and then transfering that call out to another
number. Problem is that the call rings out but the moment the other party
pickups both legs of the call are disconnected give Cause code 16. 

 

****************************************************************************
*****************************************

Dialplan:

[zap_bridge]

exten => s,1,answer()

exten => s,n,Dial(ZAP/g0/4168889999)

****************************************************************************
*****************************************

 

 

****************************************************************************
****************************************

CLI Output:

    -- Called g0/4168889999

    -- Zap/2-1 is proceeding passing it to Zap/1-1

    -- Zap/2-1 is ringing

    -- Zap/2-1 answered Zap/1-1

    -- Native bridging Zap/1-1 and Zap/2-1

    -- Channel 0/1, span 1 got hangup request, cause 16

    -- Hungup 'Zap/2-1'

  == Spawn extension (zap_bridge, s, 2) exited non-zero on 'Zap/1-1'

    -- Hungup 'Zap/1-1'

****************************************************************************
*****************************************

 

 

****************************************************************************
*****************************************

Here is PRI debug:

Starting just before Channel two is connected until both channels are
disconnected (maybe FACILITY 98 is of interest?!):

 

< Message type: CONNECT (7)

q931.c:3626 q931_receive: call 32865 on channel 2 enters state 10 (Active)
> Protocol Discriminator: Q.931 (8)  len=5
> Call Ref: len= 2 (reference 97/0x61) (Originator)
> Message type: CONNECT ACKNOWLEDGE (15)
    -- Zap/2-1 answered Zap/1-1

    -- Native bridging Zap/1-1 and Zap/2-1
> Protocol Discriminator: Q.931 (8)  len=27
> Call Ref: len= 2 (reference 96/0x60) (Originator)
> Message type: FACILITY (98)
> [1c 14 91 a1 11 02 01 06 06 07 2a 86 48 ce 15 00 08 30 03 02 01 61]
> Facility (len=22, codeset=0) [ 0x91, 0xA1, 0x11, 0x02, 0x01, 0x06, 0x06,0x07, '*', 0x86, 'H', 0xCE, 0x15, 0x00, 0x08, '0', 0x03,
0x02, 0x01, 'a' ]

PROTOCOL 11

A1 0011 (CONTEXT SPECIFIC [1])

  02 0001 06 (INTEGER: 6)

  06 0007 2A 86 48 CE 15 00 08 (OBJECTIDENTIFIER: 2a 86 48 ce 15 00 08)

  30 0003 (SEQUENCE)

    02 0001 61 (INTEGER: 97)

< Protocol Discriminator: Q.931 (8)  len=9

< Call Ref: len= 2 (reference 96/0x60) (Terminator)

< Message type: DISCONNECT (69)

< [08 02 80 90]

< Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0
Location: User (0)

<                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event
(1) ]

-- Processing IE 8 (cs0, Cause)

q931.c:3826 q931_receive: call 32864 on channel 1 enters state 12
(Disconnect Indication)

    -- Channel 0/1, span 1 got hangup request, cause 16

NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Active, peerstate Connect
Request

q931.c:3015 q931_disconnect: call 32865 on channel 2 enters state 11
(Disconnect Request)
> Protocol Discriminator: Q.931 (8)  len=9
> Call Ref: len= 2 (reference 97/0x61) (Originator)
> Message type: DISCONNECT (69)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0Location: Private network serving the local user (1)
>                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event(1) ]

NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Disconnect Indication,
peerstate Disconnect Request

q931.c:2967 q931_release: call 32864 on channel 1 enters state 19 (Release
Request)
> Protocol Discriminator: Q.931 (8)  len=9
> Call Ref: len= 2 (reference 96/0x60) (Originator)
> Message type: RELEASE (77)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0Location: Private network serving the local user (1)
>                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event(1) ]

    -- Hungup 'Zap/1-1'

< Protocol Discriminator: Q.931 (8)  len=5

< Call Ref: len= 2 (reference 96/0x60) (Terminator)

< Message type: RELEASE COMPLETE (90)

q931.c:3766 q931_receive: call 32864 on channel 1 enters state 0 (Null)

NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null

NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null

< Protocol Discriminator: Q.931 (8)  len=5

< Call Ref: len= 2 (reference 97/0x61) (Terminator)

< Message type: RELEASE (77)

q931.c:3801 q931_receive: call 32865 on channel 2 enters state 0 (Null)

NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Release
Request
> Protocol Discriminator: Q.931 (8)  len=9
> Call Ref: len= 2 (reference 97/0x61) (Originator)
> Message type: RELEASE COMPLETE (90)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0Location: Private network serving the local user (1)
>                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event(1) ]

NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null

NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null

****************************************************************************
*****************************************

 

Any input and thought is appreciated on this. This is really annoying me as
there are no pointers as to why LibPRI is asking to disconnect once the
channel is connected.

 

Thanks,

Bruce

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20100412/a0655c48/attachment-0001.htm

Possibly Parallel Threads

Search for more maybe matching threads

asterisk users - Apr 2010 - PRI Gurus ONLY - Too complex of an issue

[asterisk-users] PRI Gurus ONLY - Too complex of an issue

[asterisk-users] PRI Gurus ONLY - Too complex of an issue

[asterisk-users] PRI Gurus ONLY - Too complex of an issue

Possibly Parallel Threads