[asterisk-bugs] [Asterisk 0016755]: E1 PRI channel 'glare', where asterisk hangups up the inbound call from network.

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16755 
====================================================================== 
Reported By:                alecdavis
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16755
Category:                   Channels/chan_dahdi
Reproducibility:            random
Severity:                   minor
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           SVN 
JIRA:                       SWP-842 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.1 
SVN Revision (number only!): 243988 
Request Review:              
====================================================================== 
Date Submitted:             2010-02-02 13:24 CST
Last Modified:              2010-04-15 11:18 CDT
====================================================================== 
Summary:                    E1 PRI channel 'glare', where asterisk hangups up
the inbound call from network.
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.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0016789 [patch] Overlap receiving timeout, plus...
====================================================================== 

---------------------------------------------------------------------- 
 (0120473) gknispel_proformatique (reporter) - 2010-04-15 11:18
 https://issues.asterisk.org/view.php?id=16755#c120473 
---------------------------------------------------------------------- 
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. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-04-15 11:18 gknispel_proformatiqueNote Added: 0120473                      
   
======================================================================