triggering a callback without Obi answering the call
RonR:
Quote from: lk96 on January 23, 2012, 03:00:38 pm
Do I have this right?
Yes. The '+' is added when the PHONE Port DigitMap is evaluated. The '+' is replaced by 0011101 when the PHONE Port OutboundCallRoute is evaluated.
Quote from: lk96 on January 23, 2012, 03:00:38 pm
If so, then the above syntax is no obvious from the admin documentation.
There's a lot about the OBi that isn't obvious from the admin documentation. :(
lk96:
OK, confirming that the revised rule worked. Thanks.
If I have it right, there is no such thing as recursive evaluation of the rule.
You simply exploit the simple fact that when **2 is dialed, Msp2 will be applied
to the dialed number which is 011301234567890 and will convert it to: **2+301234567890.
And at that point,the OutboundCallRoute will kick it, it will remove the **2, and
it will also match the "+" symbol and Msp2 is used again.
And it is at that point that the final expansion to include the desired prefix, takes place.
interesting ...
L.
lk96:
Suppose I use SP2 to get a callback from the AA. I have already configured
the SP2 digitmap as we discussed before.
What I noticed is that when I get the callback from the AA through SP2, there was no digitmap processing
performed: ie, if I have set aa(sp2(1234567890)) to get a call back to that #, and given
that SP2 is the voxbeam trunk, what I see in the call record is that the number dialed
on SP2 is just the 1234567890 part and not 0011101 1234567890 as I'd expect.
Would you have an idea why there is different digit handling in this case? Does the above
make sense?
thanks
L.
RonR:
Calls using TK format [(sp2(1234567890)] don't use a DigitMap or OutboundCallRoute, so you would have to include whatever you want to go out: SP2(001110112341234567).
lk96:
Yes, I figured that after more tests. However I did try something else that also didn't work.
I defined a user-defined digitmap that was called: Mvoxmap
If I use a term like: {(Mvoxmap):aa($1)} in the inboundcallrules, the incoming
call on SP2 that is supposed to trigger the callback fails (I get a busy tone).
And the Obi call records do not include any trace of that call.
However, if instead, I cut&paste the exact same Mvoxmap digit map directly in the inboundcallrule,
it works properly and all digit processing is done as per the rule used.
Going by the documentation I expected that I can use the (Mvoxmap) reference directly in the inbound rule.
However in my case it seems that Obi totally ignores/rejects it.
It feels like a bug to me but again I'm not 100% sure if this handling was intentional or just buggy behavior.
For the time being, I have the above work-around that works ok.
thanks again
L.
Navigation
[0] Message Index
[#] Next page
[*] Previous page