[asterisk-users] Mysterious dropped calls
Richard Mudgett
rmudgett at digium.com
Tue Jul 12 16:15:16 CDT 2011
> So I'm now using asterisk 1.8.5rc1 for Asterisk. I'm still getting
> mysterious dropped calls. This only happens on calls that are outbound
> on Dahdi and mostly happens in conference calls particularly
> 8xx-xxx-xxxx
>
> This is the output of the hangup.
>
> [Ksebpbx1*CLI>
> [0KPRI Span: 1 q931_hangup: other hangup
> PRI Span: 1 NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Active,
> peerstate Connect Request, hold-state Idle
> PRI Span: 1 q931.c:4845 q931_disconnect: Call 32985 enters state 11
> (Disconnect Request). Hold state: Idle
> PRI Span: 1
> PRI Span: 1 > DL-DATA request
> PRI Span: 1 > Protocol Discriminator: Q.931 (8) len=9
> PRI Span: 1 > TEI=0 Call Ref: len= 2 (reference 217/0xD9) (Sent from
> originator)
> PRI Span: 1 > Message Type: DISCONNECT (69)
> PRI Span: 1 TEI=0 Transmitting N(S)=51, window is open V(A)=51 K=7
> PRI Span: 1
> PRI Span: 1 > Protocol Discriminator: Q.931 (8) len=9
> PRI Span: 1 > TEI=0 Call Ref: len= 2 (reference 217/0xD9) (Sent from
> originator)
> PRI Span: 1 > Message Type: DISCONNECT (69)
> PRI Span: 1 > [08 02 81 90]
> PRI Span: 1 > Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0)
> Spare: 0 Location: Private network serving the local user (1)
> PRI Span: 1 > Ext: 1 Cause: Normal Clearing (16), class = Normal Event
> (1) ]
> -- Hungup 'DAHDI/i1/18662006965-1be'
>
> [Ksebpbx1*CLI>
> [0K == Spawn extension (from-sip, 18662006965, 1) exited non-zero on
> 'SIP/7027-00000520'
>
> [Ksebpbx1*CLI>
> [0KPRI Span: 1
> PRI Span: 1 < Protocol Discriminator: Q.931 (8) len=5
> PRI Span: 1 < TEI=0 Call Ref: len= 2 (reference 217/0xD9) (Sent to
> originator)
>
> [Ksebpbx1*CLI>
> [0KPRI Span: 1 < Message Type: RELEASE (77)
> PRI Span: 1 Received message for call 0x20984f0 on 0x7f7f804f24d0
> TEI/SAPI 0/0, call->pri is 0x7f7f804f24d0 TEI/SAPI 0/0
> PRI Span: 1 q931.c:7237 post_handle_q931_message: Call 32985 enters
> state 0 (Null). Hold state: Idle
> Span: 1 Processing event: PRI_EVENT_HANGUP
> PRI Span: 1 q931_hangup: other hangup
> PRI Span: 1 NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null,
> peerstate Release Request, hold-state Idle
> PRI Span: 1
> PRI Span: 1 > DL-DATA request
> PRI Span: 1 > Protocol Discriminator: Q.931 (8) len=9
> PRI Span: 1 > TEI=0 Call Ref: len= 2 (reference 217/0xD9) (Sent from
> originator)
> PRI Span: 1 > Message Type: RELEASE COMPLETE (90)
> PRI Span: 1 TEI=0 Transmitting N(S)=52, window is open V(A)=52 K=7
> PRI Span: 1
> PRI Span: 1 > Protocol Discriminator: Q.931 (8) len=9
> PRI Span: 1 > TEI=0 Call Ref: len= 2 (reference 217/0xD9) (Sent from
> originator)
> PRI Span: 1 > Message Type: RELEASE COMPLETE (90)
> PRI Span: 1 > [08 02 81 90]
> PRI Span: 1 > Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0)
> Spare: 0 Location: Private network serving the local user (1)
> PRI Span: 1 > Ext: 1 Cause: Normal Clearing (16), class = Normal Event
> (1) ]
> PRI Span: 1 q931_hangup: other hangup
> PRI Span: 1 NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null,
> peerstate Null, hold-state Idle
> PRI Span: 1 NEW_HANGUP DEBUG: Destroying the call, ourstate Null,
> peerstate Null, hold-state Idle
>
> Any ideas?
The decision to drop the call within Asterisk has already been made
and is not shown in the trace. This trace is just showing the
clearing of the call being initiated by the Asterisk side with a
cause of normal clearing. Nothing is unexpected here.
You need to capture debug output of earlier events to figure this out.
Richard
More information about the asterisk-users
mailing list