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

[Melcon Moraes]

Freaking "hit send early, hit send often". Forget to thank you.

Thanks again for your time.

[]'s
MM

On Fri, Oct 10, 2008 at 12:58 PM, Melcon Moraes <melcon at gmail.com> wrote:

> ¡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/c4b1d621/attachment-0001.htm