Unanswered Email
R_Chandra:
Quote from: RonR on September 18, 2011, 12:11:46 pm
R_Chandra,
Although there are some similarities, the OBi Digit Map syntax is not regexp : OBi Device Administration Guide
Never said it was...You merely inferred I thought it was. I was merely stating the fact that I encountered the mentioned difficulty while writing procmail recipes. Your statement would be akin to me mentioning "although there are some similarities, SIP addresses are not email addresses."
Some references on regexps (e.g. Emacs docs) refer to the greediness of the match, with a postfix operator ("?") to limit the match. Too bad there doesn't seem to be a digit map analogue.
Quote from: RonR on September 18, 2011, 12:11:46 pm
Regardless of what you, I, or anyone else feels is intuitive or unintuitive, the fact remains that (@@.'@'@@.) conforms to the documented allowable syntax. Most importantly, it works perfectly and exactly as expected and intended EXCEPT that it causes the parsing of the Star Code script action 'coll(VAR)' to fail. This is clearly a bug in the Digit Map Processor and/or the coll(VAR) function parser.
...which is why I brought up the possibility that not using [^@] might be including an asterisk, and therefore eating your * codes. Just because something is expressed syntactically correctly doesn't mean it operates as you expect in all cases with every example of input. See what I wrote about matching "@" in procmail recipes. Hmmm...not quite sure if eating * codes conforms to documented behavior or not. But I'm leaning towards "not."
Quote from: RonR on September 18, 2011, 12:11:46 pm
OBihai's response (only after repeated prodding) that "The digit map rule you intended to use is not supported" plus "The solution is to use the following Digit map rule: |[^'@'][^'@'].'@'@@.]|", which isn't even syntactically correct, totally disables the OBi's operation, and couldn't possibly have been tested, wasn't bad, it was insulting.
On that we can agree thoroughly. They at least need to provide syntatically correct information, and better still, test their theories before disseminating that information. Making a typo is not an excuse; they should be copying/pasting from a working config into a message, not rekeying. Even better, copy/paste from the message back into some device, and test...to make sure nothing was missed in copying from the device and pasting into the message.
Well, in any case...good luck. I still haven't seen a response to the Opera 11.5x inoperability message I posted. Thank goodness I'm not dependent at the moment on Obihai fixing that. Too bad I can't share my fix with everyone else because I would likely be violating their copyright on their (JavaScript) software.
Oh, one other thing I'll add onto this after posting the first time...one thing I did not see the first time around in reading the DM syntax: "The last two elements imply that the OBi digit maps are recursive. [...]. It is important that you do not specify digit maps that lead to infinite recursion. For example, a digit map must not include a named embedded digit map that references itself." I hate to have to explain to the OBi folks that the very definition of "recursive" is self-reference, whether direct or indirect. So I'm not sure OBi is so great at communicating in the first place.
RonR:
Quote from: RonR on September 13, 2011, 04:08:52 pm
Quote from: OBiSupport on September 08, 2011, 04:52:51 pm
Please afford us a more time to study the issue in this thread.
Obihai support,
Another 5 days have elapsed. No answers to any of the questions I asked have been provided.
Attempting to reproduce the bug I reported in this thread and testing the non-functioning solution you provided cannot possibly take more than 5 minutes each.
Has any progress been made in this area?
Another 14 days have elapsed and no response from Obihai.
OBiSupport:
The @@.@@ syntax is not supported. If you can, please use the suggested work-around.
On applying trunking functionality around the mpli/pli substitution capability - this applies per phone and per auto-attendant only.
Thank you again for your support and assistance.
support@obihai.com
RonR:
Do you even read these posts and emails? I've put considerable effort into spelling things out in excruciating detail for you, but it appears you haven't bothered to take the time to read any of it. Let me try once again.
Quote from: OBiSupport on September 27, 2011, 01:25:45 pm
The @@.@@ syntax is not supported.
@@.@@ isn't the syntax there is a problem with or even what's being discussed in the emails and this thread.
@@.'@'@@. is the syntax in question. You repeatedly say it's not supported, but in fact, it works perfectly with the exception of a very limited undesired side-effect that shouldn't be occurring. Please explain why it doesn't comply with the syntax rules documented in the OBi Device Administration Guide and isn't supported.
Quote from: OBiSupport on September 27, 2011, 01:25:45 pm
If you can, please use the suggested work-around.
I've repeatedly tried to use your suggested work-around. If it's used, NO outgoing calls can be made. I've pointed this out repeatedly in emails and this thread. Why don't you take five minutes and test it yourself and see that what you suggested totally breaks the OBi. Regardless of what you dial, there's a 10-second delay followed by a fast busy.
Quote from: OBiSupport on September 27, 2011, 01:25:45 pm
On applying trunking functionality around the mpli/pli substitution capability - this applies per phone and per auto-attendant only.
I know that mpli/pli substitution is currently only applied to the PHONE Port and Auto Attendant DigitMap and OutboundRoute. I exchanged numerous emails with you explaining why it makes sense to apply it to the InboundCallRoute also. You agreed and said you could do it. Why you now have amnesia is a mystery.
OBiSupport:
Quote from: RonR - Today at 02:35:09 PM
Do you even read these posts and emails?
Yes. We read your posts and e-mails. We really appreciate the thought and effort you expend to help the OBi user community.
Quote from: RonR - Today at 02:35:09 PM
I've repeatedly tried to use your suggested work-around. If it's used, NO outgoing calls can be made.
As the suggested work-around does not work for your application, there is no solution.
Quote from: RonR - Today at 02:35:09 PM
You agreed and said you could do it. Why you now have amnesia is a mystery.
Here, we are stating the current functionality. At this time, there is no date as to when the current functionality will be modified.
Thank you your support.
Navigation
[0] Message Index
[#] Next page
[*] Previous page