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

[Melcon Moraes]

¡Hola!, ¿que tal Moy?

On Fri, Oct 10, 2008 at 12:22 AM, Moises Silva <moises.silva at gmail.com>wrote:

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


No worries. :) Things are inline.

>
>
> > 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.


Yes, that's the odd thing.

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


I cannot guarantee that to you, but I can tell you for sure that without any
changes, if I direct connect the PBX to the TELCO, it works ok. And - now
the freak show - if I use it with Unicall it works too(it's been running
with Unicall for quite some time).

My Unicall settings are :

-- unicall.conf --
supertones=br
protocolclass=mfcr2

protocolvariant=br,23,4
context=from-pstn
group=1
channel => 1-15

protocolvariant=br,3,23
context=from-pbx
group=2
channel => 32-46,48-62

-- end unicall.conf --

And I'm using unicall-0.0.3pre9 and spandsp-0.0.3pre22.

Trace: http://pastebin.ca/1224603


Hmm, I saw something. According to Underwood, ANI and Category are the first
to be get, then comes DNIS. This is the behaviour you can see at the traces.


Is this right? If so, I just need to change the mfcr2_get_ani_first to yes
and see how it goes.



> > 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.


Forget about dynamic DNIS. I just noticed another box of mine with _00ZZ.
and it's working pretty well. It's another PBX brand tho.

I've tried mfback_timeout with even 12000 and no sucess - same behaviour -
to some International calls.

Here's the trace for that call: http://pastebin.ca/1224582

Pretty much the same thing. mfback_timeout expires and says "No more DNIS"
but the forward end does not take any action. This is the case for
mfback_timeout = 12000.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-r2/attachments/20081010/25ed4bdc/attachment.htm