<div dir="ltr">Freaking "hit send early, hit send often". Forget to thank you.<br><br>Thanks again for your time.<br><br>[]'s<br>MM<br><br><div class="gmail_quote">On Fri, Oct 10, 2008 at 12:58 PM, Melcon Moraes <span dir="ltr"><<a href="mailto:melcon@gmail.com">melcon@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div dir="ltr">¡Hola!, ¿que tal Moy?<br><br><div class="gmail_quote"><div class="Ih2E3d">On Fri, Oct 10, 2008 at 12:22 AM, Moises Silva <span dir="ltr"><<a href="mailto:moises.silva@gmail.com" target="_blank">moises.silva@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hello Melcon,<br>
<br>
Sorry for the delay of my response, I have been out most of the day.</blockquote></div><div><br>No worries. :) Things are inline.<br></div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<div><br>
> At line 67, what should happen? As far as I understand, we(the * box)<br>
> ask for more DNIS and then the mfback_timeout expired. Then we(again,<br>
> the *) sent back an A-5 and no response until the far end(analog pbx)<br>
> times out and sent us a Clear Forward.<br>
<br>
</div>You described it almost right. We ask for more DNIS and then<br>
mfback_timeout expires. In most variants, when the mfback_timout<br>
expires openr2 sends protocol error. However, some variants, like<br>
Brazil and México use this timeout to signal "There is no more DNIS".<br>
The other variants have a special signal that the other end can send<br>
us to tell us it has run out of DNIS digits, but not in this case. So,<br>
when the timeout occurrs we send a pulse to resume the MF signaling.<br>
In this case we send a pulse tone number 5, which is a request for<br>
"calling party category". When the tone 5 goes off (end of the pulse),<br>
the forward end is supposed to send us the category and continue with<br>
the call setup (ANI and Group B signals), however it seems the other<br>
end never send the category.</blockquote></div><div><br>Yes, that's the odd thing. <br></div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
Are we completely sure that the Analog PBX is configured with the<br>
Brazilian variant?</blockquote><div> </div></div><div>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).<br>
<br>My Unicall settings are :<br><br>-- unicall.conf --<br>supertones=br<br>protocolclass=mfcr2<br><br>protocolvariant=br,23,4<div class="Ih2E3d"><br>context=from-pstn<br>group=1<br>channel => 1-15<br><br></div>protocolvariant=br,3,23<div class="Ih2E3d">
<br>context=from-pbx<br>
group=2<br></div>channel => 32-46,48-62<br><br>-- end unicall.conf --<br> <br>And I'm using unicall-0.0.3pre9 and spandsp-0.0.3pre22.<br><br>Trace: <a href="http://pastebin.ca/1224603" target="_blank">http://pastebin.ca/1224603</a><br>
<br>
<br>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. <br><br>Is this right? If so, I just need to change the mfcr2_get_ani_first to yes and see how it goes.<br>
<br><br></div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><br>
> Another, i think it's related, question is about the dynamic DNIS. Is<br>
> there a way to disable it? According to some tests I 've done, when<br>
> you have something like _00ZZ. in your dialplan, the behaviour just<br>
> described happens.<br>
</div>Mmmm I don't see anything in the traces suggesting that. In fact,<br>
dynamic DNIS should *always* be a benefit. The way it works is that<br>
each time Asterisk receives a digit from DNIS, we check the dial plan<br>
to see if a pattern already matches *AND* if adding more digits would<br>
not help to match any other pattern, in that case, WE STOP requesting<br>
DNIS. This behavior should not affect any application, since it will<br>
stop asking DNIS ONLY when more digits will NOT help to match other<br>
pattern. In this case we see the Analog PBX is the one who is<br>
apparentely not sending more DNIS and we therefore assume it has no<br>
more DNIS for us. You can try incrementing the mfback_timeout<br>
parameter to 5000, there is a small chance we need more time to detect<br>
their tone.</blockquote></div><div><br>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. <br><br>I've tried mfback_timeout with even 12000 and no sucess - same behaviour - to some International calls.<br>
<br>Here's the trace for that call: <a href="http://pastebin.ca/1224582" target="_blank">http://pastebin.ca/1224582</a><br><br>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.<br>
<br></div></div><br></div>
</blockquote></div><br></div>