[asterisk-users] PRI - Native ZAP bridge fails - Is this my patch?
bruce bruce
bruceb444 at gmail.com
Fri Apr 30 09:16:14 CDT 2010
Thanks. Yeah, that was the issue. I was requesting RLT and it wasn't turned
ON with the provider. Your mentioned solution fixed it.
-Bruce
On Fri, Apr 30, 2010 at 9:59 AM, Klaus Darilion <
klaus.mailinglists at pernau.at> wrote:
> The disconnect is RECEIVED by Asterisk. So there is a problem with the
> other party.
>
> You are sending FACILITY - maybe the other party does not like FACILITY and
> hangs up.
>
> IIRC there is a setting in zapata.conf to enable/disable FACILITY.
>
> regards
> klaus
>
> Am 10.04.2010 21:46, schrieb bruce bruce:
>
> Hi Guys,
>>
>> I am calling out 416-999-1111 on Channel 1 of PRI and then calling
>> 416-999-2222 on Channel 2 of PRI. When the two channels are going to be
>> ZAP native bridged, both channels hangup and CLI show PRI cause (16).
>>
>> Asterisk Verbose *(Channel 1 already connected to party)*:
>> -- Requested transfer capability: 0x00 - SPEECH
>> -- Called g0/4169992222
>> -- 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, 8) 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
>>
>>
>> System Info:
>> *Bell Canada PRI*
>> *Asterisk 1.4.21.2 *
>> *Lib PRI 1.4.10*
>>
>> Is this my patch?
>> https://issues.asterisk.org/view.php?id=7494
>>
>>
>> Thanks,
>> Bruce
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20100430/6d71a0c5/attachment.htm
More information about the asterisk-users
mailing list