[Asterisk-Users] "Glare" condition - How well does asterisk handle?

[Steve Underwood]

Scott Stingel wrote:

>A little more research on this:
>
>I found a Dialogic flow diagram that seems to indicate what happens when
>glare occurs on an IDSN line.  So it looks like perhaps it can occur?
>Re-phrasing my original question:  "Does the asterisk PRI driver properly
>re-try an outgoing call that is dropped due to a glare condition?" 
>
>Note the chart entitled "Glare (call collision)":
>http://resource.intel.com/telecom/support/releases/winnt/sr60cpci/onldoc/htm
>lfiles/gcisdn/app_isdn.htm
>
>Regards...
>  
>
It depends how you define glare. The traditional definition is the two 
ends of a circuit trying to start a call at the same moment. Typically 
both calls foul up, and there isn't much you can do to fix it. Thing 
don't foul up in this irrevokable way with ISDN, because the circuits 
themselves are not responsible for call control. Its a message passing 
system, and the two ends can negotiate their way out of it. The CPE side 
is required, by the ISDN protocol, to give precedance to the CO side. If 
both sides initiate call setup on the same B-channel, the CO side's 
attempt succeeds. The CPE's attempt can be handled in one of two ways, 
depending on the system configuration. One option is the attempt can 
fail, and the CPE must retry/reallocate on another B-channel. The other 
is the attempt will succeed, but the message back from the CO will tell 
the CPE to use a different B-channel than the one it originally 
allocated. chan_zap has some problems with this. I fixed a bug a few 
weeks ago which stopped this kind of channel reallocation working at 
all. This week we found that what I did is not a 100% cure, and more 
work is needed. I need to get this sorted out in the next week or two.

Regards,
Steve