[Home]

Summary:ASTERISK-15565: E1 PRI channel 'glare', where asterisk hangups up the inbound call from network.
Reporter:Alec Davis (alecdavis)Labels:
Date Opened:2010-02-02 13:24:49.000-0600Date Closed:
Priority:MinorRegression?No
Status:Open/NewComponents:Channels/chan_dahdi
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) full.130x.txt
( 1) glare-2inbound.txt
( 2) release-cdr-complete.txt
Description:randomly we are experiencing an ISDN 'glare'.

Captures caught so far have been our IVR dialing back out to the PSTN, at exactly the same time an incoming network call arrives.

The issue is, asterisk hangs up on the inbound call from the network, that has the channel set to exclusive, where the outbound call has only requested a preferred channel, which later is assigned to another channel in the SETUP ACKNOLEDGE.

Looks like we have outbound precedence in a 'glare' situation, when really the inbound call is probably more important.

****** ADDITIONAL INFORMATION ******

Sequence from asterisk’s point of view @ 13:10:01 from attached file full.130x.txt

     From debug: [Feb  2 13:10:01] VERBOSE[9064] pbx.c:     -- Executing [2@ivr2-bdt-day:3] Dial("DAHDI/29-1", "DAHDI/g0/5833") in new stack

     IVR Dials out to 5833
out: CR=638 SETUP preferred channel 4, calling 96228303, Called 5833

     Outside caller dials in to 8509
in:   CR=9068 SETUP Exclusive channel 4, calling = ‘’, Called 8509

     We have a glare!

     From debug: Ring requested on channel 0/4 already in use or previously requested on span 1.  Attempting to renegotiate channel.

     Inbound call is dropped !!!!
Out:  CR=9068 RELEASE COMPLETE Cause: Requested channel not available (44), class = Network Congestion (resource unavailable) (2)

     IVR call is allowed to proceed to 5833, but on new channel – ‘5’
In:   CR=638 SETUP ACKNOWLEDGE, Exclusive channel 5

     IVR call alerting and so on..
In:   CR=638 ALERTING Exclusive channel 5
Comments:By: Alec Davis (alecdavis) 2010-02-02 13:57:53.000-0600

libpri version: SVN-branch-1.4-r1457M
DAHDI Version: SVN-branch-2.2-r7844 Echo Canceller: MG2
Asterisk SVN-branch-1.6.1-r243988M<PRE>
Equipment setup:

Telco ISDN <-pri-> ISDN PRI SWITCH  <-pri-> Fujitsu PBX extens (4XXX,5XXX)
                                   <-pri-> Asterisk Production (85XX)
                                   <-pri-> Asterisk Test (86XX)</PRE>


By: Alec Davis (alecdavis) 2010-02-03 19:34:11.000-0600

another glare today. But this didn't recover, had to issue 'dahdi restart' from CLI.

Wasn't running pri intensive debug :(

But the attached full debug file 'glare-2inbound.txt shows 2 inbound calls channel 28 and 31

and the debug print 'ALEC not new call' which is printed when the new channel is already owned.
By: Alec Davis (alecdavis) 2010-02-03 22:53:44.000-0600

Followed a call senario where the caller hangups first.<pre>
SWITCH                       ASTERISK
SETUP CR=1 CH=31       --->
    .... Normal setup ...
DISCONNECT CR=1 CH=31  --->
                      <---   RELEASE CR=1
                             insert mysql record.
                             (theory spend some time...)
RELEASECOMPLETE CR=1   --->

SETUP CR=2 CH=31       --->
                             CR2 not new call
                      <---   Channel not available
                             destroy previous call CR=1

Theory: Yet to catch one, but ready :)

The issue is, if the CDR recording takes too long, the switch sends a new call with the same channel, but asterisk hasn't yet cleared down the previous call internally, it will fail, as a call still exist on that channel??? Well not really.

If the CDR was updated before the RELEASE was sent to the switch, then the chances of missing (or processing out of order) the received RELEASE COMPLETE and destory the channel may be minimised before the next SETUP comes in.</pre>
By: Alec Davis (alecdavis) 2010-02-03 23:08:30.000-0600

uploaded release-cdr-complete.txt
capture of a normal call, which I used for the theory in the previous note.

A capture when this happens, should prove/disprove this theory.
By: Birger "WIMPy" Harzenetter (wimpy) 2010-02-04 00:00:21.000-0600

Looks like we have two different bugs here.

The first one being a wrongly handled race condition in the signaling
and the second one being an internal race condition.

As both lead to calls wrongly getting rejected, I'd rank both as major issues.
By: Birger "WIMPy" Harzenetter (wimpy) 2010-02-04 00:11:04.000-0600

First case

The situation:
Here we have both ends trying to claim the same channel at the same time.
* sends a setup with X as the preferred channel and then receives a setup with X a the exclusive channel.
Note: The was no setup ack for the sent setup.

What happens:
* rejects the received setup because the requested channel is in use.

What should happen:
* should note that it only TRIED to claim the channel but it's not negotiated yet. So effectively the channel is still free and the received setup should be acknowledged.
Just the try to claim the channel via the sent setup failed. But that issue will be handled by the other end. (which is in fact successfully done here)
By: Birger "WIMPy" Harzenetter (wimpy) 2010-02-04 00:18:34.000-0600

Second case

Here it looks like the received message (setup) is being processed before processing of the previous message (rel comp) has completed.

Unfortunately I'm unable to comment further on what happens here, but it looks like something needs to be done to ensure, the received messages are processed in received order. otherwise the state machine(s) will be out of sync.
By: Alec Davis (alecdavis) 2010-02-08 20:07:32.000-0600

2nd case. Overlap dialling race condition, addressed in ASTERISK-15594
By: Guillaume Knispel (gknispel_proformatique) 2010-04-15 11:18:34

I think the way pvt channels are directly mapped to B-Channels and reserved would make it difficult to properly implement the Q.931 protocol (or a derivative like QSIG) in regard to what must happen during channel selection collision.

In Asterisk 1.4 (and I believe 1.6) B-Channels are directly mapped to dahdi pvts and are reserved way before emission of the SETUP while they should not be completely reserved for the call before confirmation from the peer, even in the case of exclusively selected (by us) channels.

For example you can have :

initial situation: all B channels but channel 4 used.

ast 1                                          ast 2

dahdi_request                                  dahdi_request
reservation chan 4 crA                         reservation chan 4 crB


                    Setup crA (chan 4 pref)
                   ------------------------->  
                    Setup crB (chan 4 excl)
                   <-------------------------

                    Release Complete crA        pri_dchannel:
                   <-------------------------   no chan available
pri_dchannel:       Release Complete crB
chan 4 in use      ------------------------->  



Note that even in the excl/excl channel collision case, at least QSIG states that one of the two calls should be granted (which one depending on configuration -- i think network has priority), while this also would of course not be the case if two Asterisk are talking to each others, or in some configurations with one Asterisk talking to a compliant equipment.
By: Richard Mudgett (rmudgett) 2010-12-22 14:55:03.000-0600

Issue ASTERISK-15594 has nothing to do with glare.