[asterisk-r2] OR2 Debug trace - Calls do not complete

[Moises Silva]

Hello Melcon,

Sorry for the delay of my response, I have been out most of the day.

> At line 67, what should happen? As far as I understand, we(the * box)
> ask for more DNIS and then the mfback_timeout expired. Then we(again,
> the *) sent back an A-5 and no response until the far end(analog pbx)
> times out and sent us a Clear Forward.

You described it almost right. We ask for more DNIS and then
mfback_timeout expires. In most variants, when the mfback_timout
expires openr2 sends protocol error. However, some variants, like
Brazil and México use this timeout to signal "There is no more DNIS".
The other variants have a special signal that the other end can send
us to tell us it has run out of DNIS digits, but not in this case. So,
when the timeout occurrs we send a pulse to resume the MF signaling.
In this case we send a pulse tone number 5, which is a request for
"calling party category". When the tone 5 goes off (end of the pulse),
the forward end is supposed to send us the category and continue with
the call setup (ANI and Group B signals), however it seems the other
end never send the category.

Are we completely sure that the Analog PBX is configured with the
Brazilian variant?

> Another, i think it's related, question is about the dynamic DNIS. Is
> there a way to disable it? According to some tests I 've done, when
> you have something like _00ZZ. in your dialplan, the behaviour just
> described happens.
Mmmm I don't see anything in the traces suggesting that. In fact,
dynamic DNIS should *always* be a benefit. The way it works is that
each time Asterisk receives a digit from DNIS, we check the dial plan
to see if a pattern already matches *AND* if adding more digits would
not help to match any other pattern, in that case, WE STOP requesting
DNIS. This behavior should not affect any application, since it will
stop asking DNIS ONLY when more digits will NOT help to match other
pattern. In this case we see the Analog PBX is the one who is
apparentely not sending more DNIS and we therefore assume it has no
more DNIS for us. You can try incrementing the mfback_timeout
parameter to 5000, there is a small chance we need more time to detect
their tone.

Moisés Silva

-- 
"I do not agree with what you have to say, but I'll defend to the
death your right to say it." Voltaire