[asterisk-bugs] [LibPRI 0017172]: PRI Zap native Bridge fails upon connect of second channel
Asterisk Bug Tracker
noreply at bugs.digium.com
Mon Apr 12 21:50:56 CDT 2010
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=17172
======================================================================
Reported By: bruceb
Assigned To:
======================================================================
Project: LibPRI
Issue ID: 17172
Category: General
Reproducibility: always
Severity: major
Priority: normal
Status: new
Asterisk Version: Older 1.4 - please test a newer version
JIRA:
SVN Branch (only for SVN checkouts, not tarball releases): trunk
SVN Revision (number only!):
Disclaimer on File?: N/A
Request Review:
======================================================================
Date Submitted: 2010-04-12 19:07 CDT
Last Modified: 2010-04-12 21:50 CDT
======================================================================
Summary: PRI Zap native Bridge fails upon connect of second
channel
Description:
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 results in a hangup. Problem is that the call rings out but the
moment the 2nd party pickups both legs of the call are disconnected given
Cause code 16.
**********************************************************************
Incoming call is sent to this context to be bridge with another channel:
[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
======================================================================
----------------------------------------------------------------------
(0120310) bruceb (reporter) - 2010-04-12 21:50
https://issues.asterisk.org/view.php?id=17172#c120310
----------------------------------------------------------------------
transfer=no in zapata.conf fixed the problem. Since RLT is a feature on
PRI for NI2 and is supported on DMS100, this doesn't seem to be a bug but
rather a feature which needs to be turned on and off based on service
availability. Please close but keep records so no one else wastes a whole
day on this :-)
Issue History
Date Modified Username Field Change
======================================================================
2010-04-12 21:50 bruceb Note Added: 0120310
======================================================================
More information about the asterisk-bugs
mailing list