asterisk users - Sep 2004 - PRI D-channel signalling error? "Ring reques ted onchannel 0/1 a lready in use on span 1. Hanging up owner."

Now that's quite interesting - yes, this is a two way span. I thought that
the D-channel negotiation that happens before the B-channel is set up would
have implicitly avoid the glare condition through signalling the
intent-to-use to the resource to the remote end (a-la E&M wink start). 

So what seems to be happening in my case is my CPE is set for a
'Descending'
b channel sequence and Asterisk is set for same, thus the high probablility
of glare. I can change the direction of my CPE which will solve the problem
in this case as I own both ends of the link, but in a telco situation where
Asterisk is the CPE how would I set it to be be the opposite of the serving
central office? PRI b-channel sequence ordering in Asterisk can't be as
simple as changing the zap group prefix in the Dial() command can it? Ie. g
vs. G?
> -----Original Message-----
> From: Peter Svensson [mailto:psvasterisk@psv.nu]
> Sent: September 29, 2004 12:23 AM
> To: dboyd@fullmoonsoft.com; Asterisk Users Mailing List - 
> Non-Commercial
> Discussion
> Subject: RE: [Asterisk-Users] PRI D-channel signalling error? "Ring
> requested onchannel 0/1 a lready in use on span 1. Hanging up owner."
> 
> 
> On Tue, 28 Sep 2004, David Boyd wrote:
> 
{clip}
> > 
> > Sounds like it could be glare, is the span two way?
> 
> The q931 specification (5.7) seems to say that there can be a 
> conflict of 
> channels, if both the cpe and the net selects the same B 
> channel for one 
> call each at the same time. I guess this can be prevented if the cpe 
> allows the net to select the B channel for the outgoing calls 
> (Any Channel 
> Acceptable).
> 
> Barring that, a contention can occur and is handled by the cpe side 
> clearing its still unconnected call. The cpe side could retry 
> the call on 
> a different B channel at that point.
> 
> >From q very quick look at chan_zap and the messages from a 
> pri intense 
> debug it seems that Asterisk selects a B channel and requests that 
> particular channel from the net. 
> 
> For the normal isdn configuration (the net hunts from low 
> channels, the 
> cpe hunts from high channels) there should rarely be a 
> collision unless 
> the trunk is close to saturation, in which case congestion _is_ the 
> correct result.
> 
> Peter
>