bruce bruce
2010-Apr-13 02:49 UTC
[asterisk-users] PRI Gurus ONLY - Too complex of an issue - SOLVED
Told you it was too complex of an issue :-) I figured to do this in zapata.conf and all is fine now: transfer=no That was the magic two letter which was sending a request for RLT feature on the line. Set transfer to "no" and all worries gone. Thanks for the input everyone. -Bruce On Mon, Apr 12, 2010 at 10:10 PM, bruce bruce <bruceb444 at gmail.com> wrote:> Futher check into the PRI debug I am seeing this which actually relates to > TBCT and AOC-E error in /usr/src/libpri/pri_facility.c: > > > 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 03] > > Facility (len=22, codeset=0) [ 0x91, 0xA1, 0x11, 0x02, 0x01, 0x06, 0x06, > 0x07, '*', 0x86, 'H', 0xCE, 0x15, 0x00, 0x08, '0', 0x03, 0x02, 0x01, 0x03 ] > > Those error codes specifically relate to RLT or TBCT and AOC-E. > > My question now is, how to avoid Asterisk from doing a TBCT while this is > not a TBCT and I want both channels to stay home so I can do call recording. > > Thanks, > Bruce > > > > > On Mon, Apr 12, 2010 at 8:51 PM, bruce bruce <bruceb444 at gmail.com> wrote: > >> It just hit me that you are talking about TBCT. I don't think I am doing >> TBCT as I still want both channels to keep two lines of my PRI occupied. In >> addition, I would be interested to know how TBCT is done over PRI. I know >> that this can be done over analogue with flash(). >> >> Can you please elaborate a bit so that TBCT is avoided and all calls are >> bridged at PBX level. >> >> Thanks, >> Bruce >> >> On Mon, Apr 12, 2010 at 4:14 PM, Don Kelly <dk at donkelly.biz> wrote: >> >>> 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: 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 >>> >>> >>> >>> -- >>> _____________________________________________________________________ >>> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >>> New to Asterisk? Join us for a live introductory webinar every Thurs: >>> http://www.asterisk.org/hello >>> >>> 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/20100412/17a78460/attachment.htm
Possibly Parallel Threads
Wisdom of the Ancients
