[asterisk-users] PRI Gurus ONLY - Too complex of an issue
bruce bruce
bruceb444 at gmail.com
Mon Apr 12 21:10:12 CDT 2010
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/c818828c/attachment-0001.htm
More information about the asterisk-users
mailing list