Hi,
I am having issues when dialing out using my Pri channels. Some calls get disconnected for an unknown reason. All I see on my SIP application side is a Bye that Asterisk sends.
Is there a way to get more information about the hangup of my pri channel? How can I get the detailed report of the hangup?
Thanks,
On the Asterisk CLI you can enable pri debugging by issue the command ‘pri debug span X’. X being the span number. You can keep a running log of the console output with ‘asterisk -vvvr|tee /tmp/astlog’ and making sure you turn on the pri debug. The pri debug has ‘<’ or ‘>’ next to the messages. ‘>’ means Asterisk is sending the message and ‘<’ means the far switch(telco) is sending the message to Asterisk. You will want to find the ‘DISCONNECT’ message and figure out if Asterisk disconnected the call or the telco did.
Hello,
This is what I was actually doing, but unfortunately I don’t get much information when the DISCONNECTION takes place. I see that the DISCONNECT originates from Asterisk for an unknown reason.
I see this in my logs, donno if you can help me understand what is going on:
Thanks…
Ok so the disconnect is coming from Asterisk and it’s a regular PRI disconnect. You will need to turn on debug in logger.conf and try and post that here or use pastebin. It will be a lot of info so probably use pastebin. This should tell us why Asterisk disconnected the call.
Hello,
Setting the debug logs, I reproduced the Hangup. Following is what I see for this call in the Log:
===============================================
Sep 12 17:40:16 DEBUG[10366] channel.c: Got a FRAME_CONTROL (5) frame on channel Zap/2-1
Sep 12 17:40:16 DEBUG[10366] channel.c: Bridge stops bridging channels SIP/192.168.0.104-08cb94e0 and Zap/2-1
Sep 12 17:40:16 DEBUG[10366] chan_zap.c: Set option AUDIO MODE, value: ON(1) on Zap/2-1
Sep 12 17:40:16 DEBUG[10366] chan_zap.c: Hangup: channel: 2 index = 0, normal = 19, callwait = -1, thirdcall = -1
Sep 12 17:40:16 DEBUG[10366] chan_zap.c: Not yet hungup… Calling hangup once with icause, and clearing call
Sep 12 17:40:16 DEBUG[10366] chan_zap.c: disabled echo cancellation on channel 2
Sep 12 17:40:16 DEBUG[10366] chan_zap.c: Set option TDD MODE, value: OFF(0) on Zap/2-1
Sep 12 17:40:16 DEBUG[10366] chan_zap.c: Updated conferencing on 2, with 0 conference users
Sep 12 17:40:16 DEBUG[10366] chan_zap.c: Set option AUDIO MODE, value: OFF(0) on Zap/2-1
Sep 12 17:40:16 DEBUG[10366] chan_zap.c: disabled echo cancellation on channel 2
Sep 12 17:40:16 DEBUG[10366] app_dial.c: Exiting with DIALSTATUS=ANSWER.
Sep 12 17:40:16 DEBUG[10366] pbx.c: Function result is 'XXXXXXXXX’
Sep 12 17:40:16 DEBUG[10366] pbx.c: Function result is 'XXXXXXXXX’
Sep 12 17:40:16 DEBUG[10366] pbx.c: Function result is 'YYYYYYYYYY’
Sep 12 17:40:16 DEBUG[10366] pbx.c: Function result is 'default’
Sep 12 17:40:16 DEBUG[10366] pbx.c: Function result is 'SIP/192.168.0.104-08cb94e0’
Sep 12 17:40:16 DEBUG[10366] pbx.c: Function result is 'Zap/2-1’
Sep 12 17:40:16 DEBUG[10366] pbx.c: Function result is 'Dial’
Sep 12 17:40:16 DEBUG[10366] pbx.c: Function result is 'Zap/g1/5145811237’
Sep 12 17:40:16 DEBUG[10366] pbx.c: Function result is '2006-09-12 17:31:31’
Sep 12 17:40:16 DEBUG[10366] pbx.c: Function result is '2006-09-12 17:31:41’
Sep 12 17:40:16 DEBUG[10366] pbx.c: Function result is '2006-09-12 17:40:16’
Sep 12 17:40:16 DEBUG[10366] pbx.c: Function result is '525’
Sep 12 17:40:16 DEBUG[10366] pbx.c: Function result is '515’
Sep 12 17:40:16 DEBUG[10366] pbx.c: Function result is 'ANSWERED’
Sep 12 17:40:16 DEBUG[10366] pbx.c: Function result is 'DOCUMENTATION’
Sep 12 17:40:16 DEBUG[10366] pbx.c: Function result is '(null)'
Sep 12 17:40:16 DEBUG[10366] pbx.c: Function result is '1158096691.62’
Sep 12 17:40:16 DEBUG[10366] pbx.c: Function result is '(null)'
Sep 12 17:40:16 DEBUG[10366] chan_sip.c: update_call_counter() - decrement call limit counter
Sep 12 17:40:16 DEBUG[9994] chan_sip.c: Stopping retransmission on ‘ssp_1850356979_767680146_174@192.168.0.104’ of Request 102: Match Found
===============================================
I believe it has something to do with the “Got a FRAME_CONTROL (5) frame on channel Zap/2-1” message which was received right before the Hangup took place.
What does this message mean?
Thanks for the help…
Nizar
Is there anymore info that was above this output? We may even need a Sip debug since thats what the PRI channel is bridged to.
In the past whenever I have seen a PRI disconnect, and you know your PRI card is setup correctly - it is because of errors on the line -
I would FIRST call your TELCO and have them run an intrusive diagnostic on your T1. This will make your PRI un-usable but will give the best results as far as testing is concerned.
I had a similar problem here, and in just doing loop diagnostics everything came back fine, but the intrusive diagnostics would not complete because of errors on the lines, they then switched out my pair and all is good. So I would always start at the telco and work backwards…
I am having a similar issue and am wondering what your final result is/was?