Strange problems with overlap dialing from chan_lcr

Hi!
 I'm a new guy in this list. I hope I will look around soon and I'll get
the local "mentality" and adapt myself adequately.
 I have some problems using LCR together with Asterisk (V11).
 Generally, all is working well. I'm using LCR just for utilizing the
BRI cards from Asterisk, as I can't compile chan_misdn from Ast V11 
cleanly with my current kernel and mISDN packages.
 So, to describe the problem: Something strange happens, when I try to
pass overlap dialing over Asterisk core from LCR to another outgoing
channel (i.e. to perform "transit dialing" or "overdialing"). Let's
imagine the simplest case:
 There is an extension in the dialplan:
 exten => 80,1,Dial(DAHDI/g1)
 After dialing the prefix 80, it immediately accesses the outgoing trunk
(DAHDI PRI). I can hear the dialtone from the remote exchange and I'm
supposed to dial through the bridge.
 However, the dialing makes problems. According to a lot of traces I
did on all three entities (in LCR, in my Asterisk and in the remote
exchange), the following is happening obviously:
 Dialing the first digit: LCR sends DTMF frame to Asterisk. 
I modified the source to use just AST_FRAME_DTMF instead of _BEGIN and
_END pair, because Ast V11 can handle it well and other channels are
doing it as well. Asterisk Frame Tracer sees it, however, Asterisk
doesn't send INFO with the digit to the peer. So, the dialtone continues
to buzz in my ear.
 Dialing the SECOND digit: LCR doesn't seem to send the DTMF frame
(at least Frame Tracer facility in Asterisk doesn't see it), but
internally in LCR log it's visible it has been sent. But what's 
strange, INFO with the FIRST digit is now sent to the remote exchange,
so the dialtone finally stops.
 THIRD dialed digit causes that Frame Tracer sees the SECOND one to come,
and it is really sent to the exchange. However, the THIRD one keeps being
hidden somewhere in the sub-space :-). And so on. Fourth digit causes
that the third one is released and sent etc. Sometimes, for longer 
numbers, it seems that the hiding queue is able to accomodate 2 digits!
So, to dial 8-digit number properly, it's necessary to add at least 2
(TWO) # characters at the end, which hopefully kick the last real digit
out of this hiding queue to the exchange, thus making the connection.
 Please note that other originating technologies capable of true overlap
dialing (DAHDI/PRI|Analog, IAX2, SCCP, even SIP with a special setup)
are not making any problems and the digits are fluently transmitted over
the core to the remote exchange. Just chan_lcr makes the exception.

With regards,
  Pavel