[asterisk-users] PRI Gurus ONLY - Too complex of an issue
bruce bruce
bruceb444 at gmail.com
Mon Apr 12 17:49:56 CDT 2010
Thanks for the input Don.
Hmmm....I am not understanding the comment here. I am not doing any flash()
or transfer() but rather just dial out and native zap bridge should just
connect two channels and only hangup both channel when one party hangs up.
Here is what should happen:
Call comes in and goes to context zap_bridge.
[zap_bridge)
exten => s,1,answer
exten => s,n,Dial(ZAP/g0/14167778888)
But what happens instead is the moment that 416-777-8888 picks up and PRI
debug shows call active state 10 then there is a request to hangup and both
channels go down. This is wrong.
If one leg of call is SIP, e.g. Dial(SIP/sip_provider/4167778888) then
everything proceeds fine. Also if a channel from an analogue card is use for
the second leg, e.g. Dial(ZAP/g1/4167778888) then native zap bridge still
works.
I think someone should be able to find something fishy in the PRI debug that
I posted. Please help!!!
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/4dc4e6c5/attachment.htm
More information about the asterisk-users
mailing list