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